[Gc] Gc segfault with gcc-3.4 and Gc segfault under valgrind

Andrew Haley aph at redhat.com
Thu Nov 16 04:46:26 PST 2006


Eric Deplagne writes:
 >   Hi,
 > 
 >     I've found out what was causing the segfault with gcc-3.4, and it
 >     was not the gc.
 > 
 >     It was in fact the choice-point library, which also deals with the stack,
 >     in order to release the constraint of longjmp being called from a function
 >     called from the function calling setjmp.
 > 
 >     Let me explain what was going on, it's a good piece of gcc optimisation problem.
 > 
 >     The problem is the use of an asm() instruction to get the stack pointer,
 >     as the following simple test_asm.c shows:
 >     (btw, I could not reproduce it on any other gcc than gcc-3.4,
 >      so maybe a (know ?) gcc-3.4 bug, or is it simply a bad idea in the first place ?)
 > 
 >     #include <stdio.h>
 > 
 >     void *s1;
 >     void *s2;
 > 
 >     int main(void) {
 >       void *s3;
 >       
 >       asm ("mov %%esp,%0" : "=g" (s1) : : "esp");
 > 
 >       asm ("mov %%esp,%0" : "=g" (s2));
 > 
 >       s3=(void *)(((int)s1)+((int)s2));
 > 
 >       printf("s3=s1+s2=%p\n",s3);
 > 
 >       printf("s1=%p, s2=%p\n",s1,s2);
 > 
 >       s3=(void *)(((int)s1)+((int)s2));
 > 
 >       printf("s3=s1+s2=%p\n",s3);
 > 
 >       return 0;
 >     }

It's not a bug.

gcc is reordering instructions and eliminating memory accesses.  The
essential problem here is that gcc isn't being told enough about the
data flow in the asm instructions: they have no inputs and an output,
and apart from the clobber they are identical.  So, gcc knows that
these asms will give identical results, no matter where they are
executed.  gcc also knows that s3 may be replaced by (s1+s2) and that
s2==s1.

gcc doesn't know that sp is used as an input to these asms.

I'd make the asms volatile, which will prevent gcc from eliminating
them or redordering them.

Andrew.



More information about the Gc mailing list