This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Does/can ld edit .stab sections?


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).
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, 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]