Re: ld corrupting .cfi_label uses

[Alan Modra <amodra at gmail dot com>]

On Fri, Mar 03, 2017 at 12:28:46AM -0700, Jan Beulich wrote:
> >>> 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.

The problem for ppc64 is that sizing and initial eh_frame contents
describing linker generated stubs needs to be done early, before final
layout of sections.  Offsets from eh_frame to the stubs are written
later.  The eh_frame editing done by bfd_elf_discard_info comes beteen
these two steps.  So we need to make sure the eh_frame editing doesn't
change anything before writing the offsets.  I suppose we could parse
the CIEs and FDEs in elf64-ppc.c, but what I do at the moment is make
sure they are generated in a way that won't be changed by the eh_frame
editing.  This is possible due to CIE merging keeping the earliest CIE
seen, and ppc64 arranging to put the linker generated eh_frame first.

> > 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).

gas doesn't generate a 64-bit eh_frame, and elf-eh-frame.c doesn't
support 64-bit eh_frame.  So not a problem.

> 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?

The 4-s after the tc_cfi_reloc_for_encoding call?  That's all fairly
new code only used by mips at the moment, where the reloc size is
always 4 bytes.  Yes, it would be better to generalize the code but
I'm not going to rush to do that..

-- 
Alan Modra
Australia Development Lab, IBM