[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: ccoutant at google dot com
Subject: [Bug gold/17366] gold can't handle a crt1.o with an .eh_frame
Date: Wed, 10 Sep 2014 19:59:26 +0000


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:


and continuing into April:


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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]