gold vs libc
Ian Lance Taylor
iant@google.com
Thu Sep 11 00:04:00 GMT 2014
On Wed, Sep 10, 2014 at 3:52 PM, Roland McGrath <roland@hack.frob.com> wrote:
>
> Incidentally, Ian mentioned Gold having had a special case for the
> __EH_FRAME_BEGIN__ symbol. But 'git log -G__EH_FRAME_BEGIN -- gold' finds
> no point in the history where Gold's source code mentioned that symbol. Do
> you know what Ian was referring to? From
> https://sourceware.org/ml/libc-alpha/2014-04/msg00021.html:
>
> I freely grant that GCC's crtbegin.o file tries this trick in a number
> of different ways--even worse, crtend.o has trailing symbols. Because
> of this existing behaviour, gold has various special cases to make it
> continue to work. One of those special cases is for
> __EH_FRAME_BEGIN__. As you've seen, the existing special case does
> not work any more. This is an unfortunate interaction. I don't think
> it's an obvious bug.
I shouldn't have said __EH_FRAME_BEGIN__. There is no special case
for the symbol. There is a special case for the sections found in
typical crtbegin/crtend files. It's these lines in
Eh_frame::add_ehframe_input_section in gold/ehframe.cc:
if (contents_len == 0)
return false;
// If this is the marker section for the end of the data, then
// return false to force it to be handled as an ordinary input
// section. If we don't do this, we won't correctly handle the case
// of unrecognized .eh_frame sections.
if (contents_len == 4
&& elfcpp::Swap<32, big_endian>::readval(pcontents) == 0)
return false;
Ian
More information about the Binutils
mailing list