On Monday 09 October 2006 20:00, Jeff Dike wrote:
> On Thu, Oct 05, 2006 at 11:38:52PM +0200, Paolo 'Blaisorblade' Giarrusso
wrote:
> > From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> >
> > If enable is moved by GCC in a register its value may not be preserved
> > after coming back there with longjmp(). So, mark it as volatile to
> > prevent this; this is suggested (it seems) in info gcc, when it talks
> > about -Wuninitialized. I re-read this and it seems to say something
> > different, but I still believe this may be needed.
> >
> > Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> > ---
> >
> > arch/um/include/longjmp.h | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/um/include/longjmp.h b/arch/um/include/longjmp.h
> > index e93c6d3..e860bc5 100644
> > --- a/arch/um/include/longjmp.h
> > +++ b/arch/um/include/longjmp.h
> > @@ -12,7 +12,8 @@ #define UML_LONGJMP(buf, val) do { \
> > } while(0)
> >
> > #define UML_SETJMP(buf) ({ \
> > - int n, enable; \
> > + int n; \
> > + volatile int enable; \
> > enable = get_signals(); \
> > n = setjmp(*buf); \
> > if(n != 0) \
>
> I agree with this, but not entirely with your reasoning. The
> -Wuninitialized documentation just talks about when gcc emits a
> warning.
>
> What we want is a guarantee that enable is not cached in a register,
> but is stored in memory. What documentation I can find seems to imply
> that is the case ("accesses to volatile objects must have settled
> before the next sequence point").
>
> However, given the prevailing opinion that essentially all volatile
> declarations are hiding bugs, I wouldn't mind a bit of review of this
> from someone holding this opinion.
I agree with that, so I think Al (whom I cc'ed) will be able to evaluate this.
- however I think that the problem with volatile is that it does not have any
semantic wrt cache - volatile does not even work with host-to-device
operation (the thing it was thought for) if you have reasonable caches -
unless the var is in a MMIO region with disabled caches.
So relying on volatile for variables shared between threads is not useful.
Note that raw_spinlock_t counter is volatile, however - separate caches
flushes or atomic operations are needed, but it may avoid the need for a full
barrier() operation or a volatile "memory" clobber - GCC knows only the
volatile object has changed, while with barrier() it must assume everything
must be reloaded. However, at least one barrier operation is needed for a
spinlock to prevent GCC from moving code outside of critical sections.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
