Re: ld corrupting .cfi_label uses

[Alan Modra <amodra at gmail dot com>]

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