ld corrupting .cfi_label uses
Alan Modra
amodra@gmail.com
Sun Feb 26 23:42:00 GMT 2017
On Fri, Feb 24, 2017 at 07:03:35AM -0700, Jan Beulich wrote:
> Hello,
>
> at first, after realizing that the problem starts with an "ld -r" invocation,
> I thought the PR 17467 was at fault here, but I then realized that if
> that was reverted, the same issue would occur during final link. The
> problem is the re-writing of .eh_frame section contents by the linker:
> This can only lead to problems, as these labels don't get moved
> together with the section contents being changed.
>
> I've been looking around for a couple of hours to find at least a
> workaround, but other than emitting something into the section
> _bfd_elf_parse_eh_frame() doesn't understand (which then would
> be at risk of breaking again with a future linker version) I can't
> seem to find anything:
> - no command line option to keep the linker from touching the
> section
> - no per-section flag indicating whether the section is the
> target of some (non-discarded) relocation
> - no other apparent mechanism
>
> While the proper solution would be to have
> _bfd_elf_write_section_eh_frame() update the relocation (and,
> if present, symbol) offsets, I would already be happy to at least
> have a way to suppress this unwanted fiddling with the section.
Since gcc does not emit separate sections for debug or eh_frame when
there are comdat section groups, I think the linker needs to always
trim FDEs corresponding to removed groups.
So, ld needs to do something about adjusting the .cfi_label
references.
--
Alan Modra
Australia Development Lab, IBM
More information about the Binutils
mailing list