This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: gold vs libc
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Cary Coutant <ccoutant at google dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Alan Modra <amodra at gmail dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Binutils <binutils at sourceware dot org>, Rafael Ãvila de EspÃndola <rafael dot espindola at gmail dot com>
- Date: Thu, 11 Sep 2014 11:33:29 -0700 (PDT)
- Subject: Re: gold vs libc
- Authentication-results: sourceware.org; auth=none
- References: <20140330042516 dot 1A88E74481 at topped-with-meat dot com> <20140330045552 dot GX18201 at bubble dot grove dot modra dot org> <20140330050615 dot 7DC5774481 at topped-with-meat dot com> <CAKOQZ8wPgdHfA9QJWQ9yVO9gVQKL=HF-rpuipCBxzsx3=TcqwA at mail dot gmail dot com> <20140331200446 dot A09B074430 at topped-with-meat dot com> <CAKOQZ8x19YZ_oyJXyxe9JST4nfaG8dDvVrdf-vmgkNWydrpsrw at mail dot gmail dot com> <20140331214025 dot E61517447E at topped-with-meat dot com> <CAKOQZ8x1W0YxJSq+X74EjMj7_02uTZq82qzhmF=oQ-cTd4S1mQ at mail dot gmail dot com> <CAHACq4oRKDGKAUu3octDCxKg2EueCyf8kHWj0t8g9+LmE3JagQ at mail dot gmail dot com> <20140910225238 dot 0B6362C39CF at topped-with-meat dot com> <CAHACq4rBr76jL+qo7Va03Ewv7PkLfrJA+_tewn7ZnMTpxBO+ug at mail dot gmail dot 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