Re: ld corrupting .cfi_label uses

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

>>> On 02.03.17 at 22:34, <amodra@gmail.com> wrote:
> On Thu, Mar 02, 2017 at 09:30:52AM -0700, Jan Beulich wrote:
>> >>> On 01.03.17 at 03:42, <amodra@gmail.com> wrote:
>> > Yeah, I've run into the padding issue myself.  It is a pain to deal
>> > with.  If one input .eh_frame has larger alignment than other
>> > .eh_frame sections for whatever reason, then padding placed before
>> > that section will be seen as a zero terminator.
>> > 
>> > I suspect that is why ld ensures FDEs are a multiple of eight in size
>> > (it would be better to look at the output section alignment) because
>> > gcc emits .eh_frame aligned to eight bytes on 64-bit targets.  You can
>> > pad with NOPs *inside* an FDE or CIE, not outside.
>> > 
>> > The following implements my suggestion re. output section alignment.
>> > That may well cure your complaint.
>> 
>> For .eh_frame with 4-byte alignment this indeed helps at least for the
>> ld -r case. I haven't got to the final link part yet, as I have to fiddle
>> with the object files in order to make the alignment such - even gas
>> emits 8-byte alignment by default. And I can't seem to spot an
>> objcopy option to alter the alignment of a section. I'll see if I can spot
>> why gas behaves this way, and if I may possibly change it.
> 
> Good.  I'm not going to commit the patch as is, because it breaks
> powerpc64.  From elf64-ppc.c:
> 
>   /* Note that the glink_eh_frame check here is not only testing that
>      the generated size matched the calculated size but also that
>      bfd_elf_discard_info didn't make any changes to the section.  */

I don't think I understand the connection here (the wording
suggests to me that ppc64 expects .eh_frame contents to not
be changed at all, which would seem to imply that there is a
way to suppress changes being made, which in turn is contrary
to my findings so far). After all your patch, aiui, reduces the
chance of changes being made. But then again I know next to
nothing about ppc specifics anyway.

> So I have some further patches for powerpc64, and am modifying
> elf-eh-frame.c to align CIEs and FDEs ideally.  Current patch looks at
> the FDE encoding to choose 4 or 8 byte alignment in order to make FDE
> range start and size naturally aligned.

That was one of my thoughts too, but would seem to collide with
the dwarf2_format_64bit case: That emits 32 bits of all ones
followed by two 64-bit quantities. DWARF2_FDE_RELOC_SIZE
being larger than 4 would the still mean misaligned fields (as much
as the two mentioned 64-bit ones already appear to be).

What I'll give a try next is overriding EH_FRAME_ALIGNMENT just
for x86-64, and only for the .eh_frame case (i.e. leave the
Dwarf side alone to minimize impact).

Speaking of DWARF2_FDE_RELOC_SIZE - the reloc handling in
output_fde() looks rather suspicious in this regard: Shouldn't, at
the very least, the three literal 4-s be DWARF2_FDE_RELOC_SIZE?
Or even more correctly, shouldn't these numbers be determined
based on the chosen reloc, and then also be used to set addr_size?

Jan