"linux-os \(Dick Johnson\)" <[email protected]> writes:
>> 00000000 <funct>:
>> 0: a1 00 00 00 00 mov 0x0,%eax
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 5: 55 push %ebp
>> 6: 89 e5 mov %esp,%ebp
>> 8: 85 c0 test %eax,%eax
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> a: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
>> 10: 75 fe jne 10 <funct+0x10>
>> 12: 5d pop %ebp
>> 13: c3 ret
>>
>> "0x0" is, of course, for relocation.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> So read the code; you have "10: jne 10", jumping to itself
> forever, without even doing anything else to set the flags, much
> less reading a variable.
The variable is tested before entering the loop, of course. But
it _is_ tested and the initial state doesn't matter.
The "0x0" may be misleading so I added the note about relocation.
It _is_ BTW correct machine code.
>> 00000000 <funct>:
>> 0: 55 push %ebp
>> 1: 89 e5 mov %esp,%ebp
>> 3: a1 00 00 00 00 mov 0x0,%eax
>> 8: 85 c0 test %eax,%eax
>> a: 75 f7 jne 3 <funct+0x3>
>> c: 5d pop %ebp
>> d: c3 ret
>
> This is the only code that works. Guess why it worked? Because
> you declared the variable volatile.
Of course. But I don't see any address recalculations.
> Now Linus declares that instead of declaring an object volatile
> so that it is actually accessed every time it is referenced, he wants
> to use a GNU-ism with assembly that tells the compiler to re-read
> __every__ variable existing im memory, instead of just one. Go figure!
That's probably overkill, I can think of more cases where "volatile"
actually makes sense. Most are probably broken anyway, especially
those that aren't (guaranteed to be) atomic but the author uses them
as if they were.
BTW: barrier() isn't a lock.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
