Re: ld corrupting .cfi_label uses

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

>>> On 27.02.17 at 00:42, <amodra@gmail.com> wrote:
> 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.

Well, .cfi_label uses are only a special case. Hand-generated
.eh_frame sections may have labels point anywhere, including
at the boundary between one CIE/FDE and another. In such
a case you can't tell whether the label marks the end of one or
the beginning of the other. So I think CIEs/FDEs with symbols
or relocations pointing into them need to be left alone, even
in the comdat case (the exception being normal linkonce
processing of course, where the entire section may still be
discarded).

My problem here is that I don't see any way to know whether
there are symbols (including local ones, but excluding the
section one) or relocations referring to a particular section
(other than going through the raw object file of course), for
easy checking in _bfd_elf_write_section_eh_frame(), or
even better already in _bfd_elf_parse_eh_frame_entry().

Jan