[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/17467] .eh_frame_hdr table overlaps
From: |
amodra at gmail dot com |
Subject: |
[Bug ld/17467] .eh_frame_hdr table overlaps |
Date: |
Sun, 12 Oct 2014 11:38:10 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=17467
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC|amodra at gmail dot com |
Assignee|unassigned at sourceware dot org |amodra at gmail dot com
--- Comment #2 from Alan Modra <amodra at gmail dot com> ---
We don't do eh_frame editing for ld -r, ever since
https://sourceware.org/ml/binutils/2003-02/msg00471.html was applied.
What's happening here is that we have multiple copies of c++ code emitted in
comdat groups, the first one I looked at being
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_, but g++ does not emit
the .eh_frame info to the group. If g++ did do this, as it should, then
duplicate .eh_frame info would be discarded along with the duplicate code
sections. Instead we get one copy of the group after ld -r and multiple copies
of the .eh_frame info for the group. That's bad because the "duplicate"
.eh_frame info may not exactly match the kept group code (it doesn't with the
example object files), and the .eh_frame_hdr lookup table will conspire to
choose the last set of .eh_frame info rather than the first (which corresponds
to the actual code, assuming a stable qsort). So there is a nasty exception
handling bug lurking to bite someone.
--
You are receiving this mail because:
You are on the CC list for the bug.