Re: Does/can ld edit .stab sections?

[Alan Modra <amodra at bigpond dot net dot au>]

On Fri, Nov 02, 2001 at 08:04:23PM +0100, Jakub Jelinek wrote:
> On Fri, Nov 02, 2001 at 10:44:31AM -0800, Geoff Keating wrote:
> > > Date: Fri, 2 Nov 2001 10:17:10 +0100
> > > From: Jakub Jelinek <jakub@redhat.com>
> > 
> > > For .eh_frame, using separate sections (without some ld support) for each
> > > .gnu.linkonce is IMHO not an option, because that will severely bloat the output
> > > (because one will have to emit a separate CIE for each such section and it
> > > may happen that the CIEs will be larger than FDEs for small
> > > functions).
> > 
> > I don't think this is how we discussed it would work.  There would be
> > a bunch of .eh_frame.* sections in .o files, but all the sections in a
> > .o file would expect to come in sequence in the final .eh_frame
> > section in the executable, so each .o would only need one CIE.
> 
> You mean one .eh_frame and a bunch of .gnu.linkonce.eh.* sections per .o
> file, right? ATM even if you write *(.eh_frame .gnu.linkonce.eh.*) the
> linker will act as if it was *(.eh_frame) *(.gnu.linkonce.eh.*) (yep, a bug
> that should be fixed).

I believe that has been fixed.  However, you may need to modify the
linker scripts.

> But even if that is fixed, you'll have lots of erratic FDEs (because if you
> want to order all .eh_frame stuff from one .o file, then another one, but
> .gnu.linkonce.t.* functions come after all .text functions

Again, I believe this is just a linker script issue.

>, the addresses
> will jump up and down), plus also one CIE per .o file, which ATM e.g.
> means one __gxx_personality_v0 dynamic relocation per .o file (ok, for
> DW_EH_PE_indirect this can be dealt by using some
> .gnu.linkonce.d.ref.__gxx_personality_v0 and similar sections),
> but if it is not DW_EH_PE_indirect, you'll have potentially hundreds of
> unnecessary __gxx_personality_v0 relocs.
> If ld optimizes this, there would be no erratic FDEs most of the time (there
> might be some e.g. if some objects were -fpic and some weren't) and minimum
> number of CIEs, and it wouldn't be too expensive to compute this during link
> time (.debug_info would be far more expensive).
> 
> 	Jakub