Re: gcc-3.4.X + glibc segfault

[Jake Page <jake at cs dot stanford dot edu>]

> 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