lkml.org 
[lkml]   [2006]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateMon, 25 Sep 2006 22:03:28 -0700
FromJeremy Fitzhardinge <>
SubjectRe: [PATCH] Linux Kernel Markers 0.13 for 2.6.17
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-09-26 07:05    [from the cache]
©2003-2010