Re: ld corrupting .cfi_label uses

[Alan Modra <amodra at gmail dot com>]

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.  */

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.

-- 
Alan Modra
Australia Development Lab, IBM