This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH] Linux Kernel Markers 0.13 for 2.6.17
- From: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- To: Jeremy Fitzhardinge <jeremy at goop dot org>
- Cc: Martin Bligh <mbligh at google dot com>, "Frank Ch. Eigler" <fche at redhat dot com>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, prasanna at in dot ibm dot com, Andrew Morton <akpm at osdl dot org>, Ingo Molnar <mingo at elte dot hu>, Paul Mundt <lethal at linux-sh dot org>, linux-kernel <linux-kernel at vger dot kernel dot org>, Jes Sorensen <jes at sgi dot com>, Tom Zanussi <zanussi at us dot ibm dot com>, Richard J Moore <richardj_moore at uk dot ibm dot com>, Michel Dagenais <michel dot dagenais at polymtl dot ca>, Christoph Hellwig <hch at infradead dot org>, Greg Kroah-Hartman <gregkh at suse dot de>, Thomas Gleixner <tglx at linutronix dot de>, William Cohen <wcohen at redhat dot com>, ltt-dev at shafik dot org, systemtap at sources dot redhat dot com, Alan Cox <alan at lxorguk dot ukuu dot org dot uk>, Karim Yaghmour <karim at opersys dot com>, Pavel Machek <pavel at suse dot cz>, Joe Perches <joe at perches dot com>, "Randy.Dunlap" <rdunlap at xenotime dot net>, "Jose R. Santos" <jrs at us dot ibm dot com>
- Date: Mon, 25 Sep 2006 22:59:24 -0400
- Subject: Re: [PATCH] Linux Kernel Markers 0.13 for 2.6.17
- References: <20060925233349.GA2352@Krystal> <20060925235617.GA3147@Krystal> <45187146.8040302@goop.org> <20060926002551.GA18276@Krystal> <20060926004535.GA2978@Krystal> <45187C0E.1080601@goop.org>
First of all, yes, gcc seems not to allow a programmer to jump between asm
labels without painfully verifying everything, as stated in
http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/gcc/Extended-Asm.html
"Speaking of labels, jumps from one asm to another are not supported. The
compiler's optimizers do not know about these jumps, and therefore they
cannot take account of them when deciding how to optimize."
however... (see below)
* Jeremy Fitzhardinge (jeremy@goop.org) 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
States :
"If your assembler instructions access memory in an unpredictable fashion,
add memory to the list of clobbered registers. This will cause GCC to not
keep memory values cached in registers across the assembler instruction
and not optimize stores or loads to that memory. You will also want to
add the volatile keyword if the memory affected is not listed in the
inputs or outputs of the asm, as the memory clobber does not count as
a side-effect of the asm. If you know how large the accessed memory is,
you can add it as input or output but if this is not known, you should
add memory. As an example, if you access ten bytes of a string, you can
use a memory input like:
{"m"( ({ struct { char x[10]; } *p = (void *)ptr ; *p; }) )} "
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".
Mathieu
OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68