ld corrupting .cfi_label uses

[Jan Beulich]

>>> On 01.03.17 at 03:42, <amodra@gmail.com> wrote:
> On Mon, Feb 27, 2017 at 01:28:25AM -0700, Jan Beulich wrote:
>> 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.
> 
> 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.

Oh, thanks! I'll see to give this a try, maybe not today, but hopefully
later this week.

Jan