Re: [RFA:] New test for bug in --gc-sections: selective6

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Sun, 24 Sep 2000, Hans-Peter Nilsson wrote:
> B::foo
> is there, as well as drop1 and drop2 for some reason, perhaps another bug.

No, that was wrong, pilot error: B::foo is there in error, but dropme1 and
dropme2 are not there, when -fno-exceptions is given.

Anyway, *with* exception-information, symbols in dropme1 and dropme2 are
referred to, from .eh_frame.  Which means, for real C++ code, where each
and every function has labels pointed to from .eh_frame, the option
--gc-sections is currently unusable.  I guess it would help if GCC was
changed to emit unique .eh_frame.mungedfname sections that could be
garbage-collected.  But as long as this still only works with gcc -static,
the feature will not be of much use to most people.

The selective6 bug looks like a architectural restriction; not easily
fixed.  IMHO it's still a bug.  It seems fixable by (mumble) changing the
type of vtable_entries_used in elf_link_hash_entry and changing
elf_gc_sections to perform two passes, or something.  Not today.

By the way, has someone looked into making --gc-sections usable with
dynamic linking?  Without giving much thought to it, it seems possible to
use it in the common case where you're not dlopen:ing DSO:s that want any
thrown-away symbols, or you can arrange to KEEP all sections with symbols
you want them to use somehow.  Similarly, we know what sections with
symbols the ordinary libraries that we link with want to import, (right?)
so mark those SEC_KEEP too.

Oh well.  End of rant.

brgds, H-P