This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

ld corrupting .cfi_label uses


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
- 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.

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

Thanks, Jan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]