Re: gold vs libc

[Roland McGrath <roland@hack.frob.com>]

> I don't like the idea of checking for specific symbol name to give
> special treatment to a section. I wouldn't mind simply making
> __EH_FRAME_BEGIN__ and __EH_FRAME_END__ linker-defined symbols that
> would override any definitions found in the object files.

The notion as I read it was that when the linker decides to rewrite
.eh_frame data, it defines these symbols accordingly.

> I could also special case by filename -- check is_in_system_directory(),
> and if true, check the filename to see if it contains "begin" or "end".

The horror, the horror.

> BTW, my copy of crtend.o doesn't define __EH_FRAME_END__. It does
> define __FRAME_END, but it's a local symbol. Having the linker provide
> __EH_FRAME_END__ would be consistent, and shouldn't break anything.
> With this proposal, __FRAME_END would get the right value anyway.
> (Until, that is, someone comes along with another crtend-like file and
> decides it needs CFI as well!)

Nothing needs or uses an end symbol (there's an in-band terminator)
and there is no canonical name for one, so I don't think you should
define one.

In fact, __EH_FRAME_BEGIN__ is not a global symbol either.  It's not
actually a canonical name.  It's just used inside crtbeginT.o, which
defines it in .eh_frame and uses it in a reloc in .text.  There is no such
symbol around at all by link time that matters.  There is just a reloc
using the STT_SECTION symbol for .eh_frame.  (At least that's what I see on
by x86_64 system.  I've never been very clear on when the assembler uses a
specific local symbol in a reloc vs reducing it to a section symbol, and I
suspect it varies across machines.)  So the symbol idea doesn't fly.

You could instead special-case a reloc against .eh_frame+0 in an input file
with an empty .eh_frame.  Off hand, I think this might well be the only
reloc against a .eh_frame input section you will ever see.  So perhaps
really the right thing to do is verify that there is at most one reloc
against .eh_frame anywhere (and perhaps that it is against an empty input
.eh_frame section) and treat it specially if so--but either error or
disable .eh_frame optimization if there are any more relocs into .eh_frame
sections.  I can't really imagine any situation with a reloc pointing into
.eh_frame whose intended semantics wouldn't be probably broken by .eh_frame
optimization.


Thanks,
Roland