Re: gc sections and .eh_frame

[Jonathan Larmour <jifl at eCosCentric dot com>]

Alan Modra wrote:
> On Wed, Jun 29, 2005 at 11:31:02PM +0100, Jonathan Larmour wrote:
>
> > I updated my sources to current binutils CVS and rebuuilt my 
> > powerpc-eabi-ld. Unfortunately I now get the following when linking an 
> > application that uses C++ exceptions:
> > `DW.ref._ZTISt9exception' referenced in section `.rodata' of 
> > /local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o): 
> > defined in discarded section `.gnu.linkonce.s.DW.ref._ZTISt9exception' of 
> > /local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o)collect2: 
> > ld returned 1 exit status
[snip]
> > multiple instances of that section name, and only one is marked to be 
> > kept, but when duplicate .gnu.linkonce sections are removed, it is the 
> > other instance that is kept, and later when GC happens, even that one is 
> > removed.
>
>
> No, GC isn't removing too many sections.  The problem is that .eh_frame,
> .gcc_exception_table, debug sections, and other sections on some targets
> are not split per-function.  When linkonce sections are removed, you are
> left with references from these sections to the removed sections.  The
> linker knows this happens for certain section names, so doesn't warn,
> but powerpc has been using .rodata instead of .gcc_exception_table..

Thanks for the explanation. I see that now.

Unfortunately it doesn't leave any sysv4 powerpc target users (including 
powerpc-linux as you said before) much better off, since the GCC change to 
stop using .rodata hasn't even been committed to the trunk yet, nevermind 
any current release branches, and won't be widely disseminated until a 
while after that. Well, they're slightly better off since at least they 
now get an error rather than silent failure :-).

But I've even less of an idea of how this could be addressed in binutils. 
The only way I can think of to identify the problematic powerpc GCC is the 
presence of .eh_frame with an absence of .gcc_except_table, and putting 
that knowledge in place in elf_link_input_bfd is a bit of a kludge. Any 
other ideas?

> A workaround is to link with --noinhibit-exec.

Ick. I'm sure we should be recommending something better than that.

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine