ld corrupting .cfi_label uses

["Jan Beulich" <JBeulich at suse dot com>]

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