Re: Does/can ld edit .stab sections?

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Nov 02, 2001 at 10:21:21AM +1030, Alan Modra wrote:
> On Thu, Nov 01, 2001 at 11:59:47AM -0500, Daniel Jacobowitz wrote:
> > 
> > Or perhaps to generate separate stab sections for each original section
> > and merge them at link time?
> 
> Yes, that is exactly what is needed.  Initial support for section groups
> has already been added to binutils, but gcc needs to be taught how to
> tell the linker about groups.  I will look into it sometime...

Are you sure separate .stab.*, .eh_frame.*, .dwarf_*.* etc. sections
are the best way to do this?
Then we're quickly approaching the 64K section limit, if for every separate
text section you need 10 other ones.

For .stab, ld already revamps that section, so I don't see why it cannot
handle this too (simply discard stabs which are against discarded sections).

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).
But when ld is taught to deal with .eh_frame (it can throw away compatible
CIEs, it can sort FDEs by increasing address, could even change absolute
encoding into pc relative to get rid of zillions of RELATIVE relocs against
.eh_frame in libs for arches which don't easily support this), I don't see
why it cannot be taught to discard FDEs against discarded sections at the
same time.

For .dwarf_* sections, again some ld support would be extremely helpful,
because ATM dwarf2 is huge (e.g. libqt has ~ 12.5MB of stabs debug info
while if built with -gdwarf-2, it has ~ 26.5MB).
And if there is some, again it should not be any problem to discard dwarf2
chunks related to discarded sections.

	Jakub