Re: ld corrupting .cfi_label uses

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

>>> Alan Modra <amodra@gmail.com> 02/27/17 12:42 AM >>>
>On Fri, Feb 24, 2017 at 07:03:35AM -0700, Jan Beulich wrote:
>> 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.

As said, I agree this ought to be the proper final solution, yet while there's
no real magic needed here, it'll likely be not exactly a non-intrusive change.
Still in the case at hand (Linux kernel) there aren't any section groups
involved, and I think the linker ought to leave the contents of .eh_frame
untouched unless it actually has a need to remove anything from it. Afaict
it is solely the padding to a multiple of 8 bytes which actually gets in the
way in my case. But obviously that's hard to verify without suppressing that
adjustment first, which didn't look safe to do in a straightforward manner as
(a) there's a later assertion to that effect and (b) there's no explanation why
the adjustment is being done in the first place, and hence it's not clear
under what conditions it may need retaining.

Jan