Re: -ffunction-sections -fdata-sections vs. string-inst

[Benjamin Kosnik <bkoz at redhat dot com>]

> However, FYI, I now see new core dumps on 7 statically built
> executables: append.st-exe, bitset_ctor.st-exe, ctor_copy_dtor.st-exe,
> element_access.st-exe, insert.st-exe, ios_members.st-exe,
> substr.st-exe

I saw them too. I looked at the string append case, and it looks like 
it's bombing out in the first throw, which is suspicious.

it looks like -ffunciton-sections alone also has the problems, for what 
it's worth.

> #0  count_fdes (this_fde=0x8059108) at ../../egcs/gcc/frame-dwarf2.c:257
> #1  0x80498ff in frame_init (ob=0x80595c0) at ../../egcs/gcc/frame-dwarf2.c:324
> #2  0x8049a56 in find_fde (pc=0x8048eb8) at ../../egcs/gcc/frame-dwarf2.c:364
> #3  0x8049fb5 in __frame_state_for (pc_target=0x8048eb8, state_in=0xbfbfc638)
>     at ../../egcs/gcc/frame-dwarf2.c:628
> #4  0x8048ecc in __throw () at ../../egcs/gcc/libgcc2.c:3937

pretty much what I saw too.

> I believe this is exposing a bug in ld on my platform since if I
> remove -Wl,--gc-sections from mkcheck, all those tests run fine again.

I don't know if it's ld or compiler related. I tried weakly to get 
jason's help with this yesterday... but we were both busy doing other 
stuff.  

(jason, did you get a chance to look at this? Could you please?)

> My opinion only, but I don't think this should stop your patch going
> in since I have looked at the build logs closely and think it is doing
> the right thing.  

hmmm. Kind of what I'm thinking too. . . any objections please voice them...

I kind of wish that I could get the -Wl,--gc-sections just used for the 
linker line instead of used on the compiler line, and -ffunction-sections 
etc just used for static compiles but I can't figure out how to do this. 

I suppose that part can get done later.

>The test should continue to include
> -Wl,--gc-sections in order to continue to flag the problem, but users
> that have a buggy ld (if my supposition is correct) can just avoid
> including that flag when they link.

> I will try to form a small testcase to go in dejagnu for this issue
> since then more GCC/binutil hackers will see it.  <...thinking...>
> Sweet, the obvious testcase fails:
> 
> int main (void)
> {
>   try
>     {
>       throw 1;
>     }
>   catch (...) {}
>   return 0;
> }

cool thanks. . . . this should help narrow it down.