[Bug gold/17366] gold can't handle a crt1.o with an .eh_frame

[ccoutant at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17366

Cary Coutant <ccoutant at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #2 from Cary Coutant <ccoutant at google dot com> ---
See the discussion starting at:

   https://sourceware.org/ml/binutils/2014-03/msg00310.html

and continuing into April:

   https://sourceware.org/ml/binutils/2014-04/msg00006.html

Gold is optimizing the .eh_frame data, then throwing the optimized result into
the output section at a point corresponding to where it saw the first .eh_frame
section that it could optimize. This is a perfectly reasonable thing to do, and
it makes no sense that the open bracket symbol is defined crtbeginT.o, which
comes after crt1.o in the link order. When crt1.o has no .eh_frame data,
everything works because the optimized data will get inserted following
crtbeginT.o.

Gnu ld likely handles this by not optimizing the .eh_frame data when
--eh-frame-hdr is not passed in, so everything appears in link order. It's
still doing the wrong thing, though, as the data in crt1.o still comes before
the __EH_FRAME_BEGIN__ symbol.

The proper solution would be to move the __EH_FRAME_BEGIN__ symbol into a file
that actually does come before any .eh_frame data.

*** This bug has been marked as a duplicate of bug 14675 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.