This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gold vs libc

On Wed, Sep 10, 2014 at 3:52 PM, Roland McGrath <> 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
>     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/

  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;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]