This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
ld corrupting .cfi_label uses
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: <binutils at sourceware dot org>
- Date: Fri, 24 Feb 2017 07:03:35 -0700
- Subject: ld corrupting .cfi_label uses
- Authentication-results: sourceware.org; auth=none
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.
Suggestions?
This raises more general concerns though:
1) Is it unreasonable to expect "ld -r" with a single input and no
other options to produce output matching its input, at least as
far as the results of linking either object into a final binary go?
2) With gas emitting 4-byte aligned/padded .eh_frame entries
for x86-64, what's the point of ld padding them to 8-byte
boundaries?
Thanks, Jan