gcc-3.4.X + glibc segfault
Jake Page
jake@cs.stanford.edu
Mon Jul 26 22:31:00 GMT 2004
> Yes, I think it was gcc-3.4.1 optimizing a bit much.
> Here's a workaround backported from cvs to glibc-2.3.2:
>
Hi,
I had those patches applied - however, it did not affect the file
(malloc.c) that I was compiling. I did have compile optimization at -O0,
though, which should disable no-unit-at-a-time completely. Just to make
sure, I compiled the file (malloc/malloc.c) with -O0 -fno-unit-at-a-time
explicitly, and the results were the same.
The thing that was baffling me was that a nearly identical piece of code
was generated correctly in the same file. I fianlly tracked it down to
the multiple different ways glibc declares weak references:
/* used by __pthread_initialize in glibc - works fine */
extern void __weak_one(void) __attribute__ ((weak));
/* works with gcc-3.4.1 IF used... */
extern void __weak_two (void);
#pragma weak __weak_two
/* used by __pthread_mutex_init in glibc (for mips at least)
BAD in gcc-3.4.1 ! */
extern void __weak_three (void);
asm(".weak " "__weak_three");
I'm assuming the problem is a 'trivial' dead code removal
optimization - since gcc doesn't know anything about the contect of the
"asm()" statement, if assumes that the "__weak_three" symbol is non-zero,
and optimized out a check like "if (__weak_three != NULL)"
I noticed that glibc-2.3.2 has a more complicated system for declaring
weak references - I will test this with it when I get the chance...
Will also put together a patch for glibc-2.2.5 to use #pragma instead of
asm() (since I've been using 2.2.5 previously, and am not sure I want to
upgrade yet...)
-Jake
------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
More information about the crossgcc
mailing list