Re: [PATCH] Linux Kernel Markers 0.13 for 2.6.17

[Jeremy Fitzhardinge <jeremy@goop.org>]

Mathieu Desnoyers wrote:
>> Mathieu Desnoyers wrote:
>>     
>>> To protect code from being preempted, the macros preempt_disable and
>>> preempt_enable must normally be used. Logically, this macro must make sure 
>>> gcc
>>> doesn't interleave preemptible code and non-preemptible code.
>>>  
>>>       
>> No, it only needs to prevent globally visible side-effects from being 
>> moved into/out of preemptable blocks.  In practice that means memory 
>> updates (including the implicit ones that calls to external functions 
>> are assumed to make).
>>
>>     
>>> Which makes me think that if I put barriers around my asm, call, asm trio, 
>>> no
>>> other code will be interleaved. Is it right ?
>>>  
>>>       
>> No global side effects, but code with local side effects could be moved 
>> around without changing the meaning of preempt.
>>
>> For example:
>>
>> 	int foo;
>> 	extern int global;
>>
>> 	foo = some_function();
>>
>> 	foo += 42;
>>
>> 	preempt_disable();
>> 	// stuff
>> 	preempt_enable();
>>
>> 	global = foo;
>> 	foo += other_thing();
>>
>> Assume here that some_function and other_function are extern, and so gcc 
>> has no insight into their behaviour and therefore conservatively assumes 
>> they have global side-effects.
>>
>> The memory barriers in preempt_disable/enable will prevent gcc from 
>> moving any of the function calls into the non-preemptable region. But 
>> because "foo" is local and isn't visible to any other code, there's no 
>> reason why the "foo += 42" couldn't move into the preempt region.  
>>     
>
> I am not sure about this last statement. The same reference :
> http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/gcc/Extended-Asm.html
>   
(This is pretty old, and this is an area which changes quite a lot.  You 
should refer to something more recent;
http://www.cims.nyu.edu/cgi-systems/info2html?/usr/local/info(gcc)Top 
for example, though in this case the quoted text looks the same.)

> I am just wondering how gcc can assume that I will not modify variables on the
> stack from within a function with a memory clobber. If I would like to do some
> nasty things in my assembly code, like accessing directly to a local variable by
> using an offset from the stack pointer, I would expect gcc not to relocate this
> local variable around my asm volatile memory clobbered statement, as it falls
> under the category "access memory in an unpredictable fashion".
>   

That not really what it means.  gcc is free to put local variables in 
memory or register, and unless you pass the local to your asm as a 
parameter, your code has no way of knowing how to find the current 
location of the local.  You could trash your stack frame from within the 
asm if you like, but I don't think gcc is under any obligation to behave 
in a deterministic way if you do.

"Unpredictable" in this case means that the memory modified isn't easily 
specified as a normal asm parameter.  For example, if you have an asm 
which does a memset(), the modified memory's size is a runtime variable 
rather than a compile-time constant.  Or perhaps your asm follows a 
linked list and modifies memory as it traverses the list.


    J