This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ld corrupting .cfi_label uses
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "Alan Modra" <amodra at gmail dot com>
- Cc: <binutils at sourceware dot org>
- Date: Thu, 02 Mar 2017 09:30:52 -0700
- Subject: Re: ld corrupting .cfi_label uses
- Authentication-results: sourceware.org; auth=none
- References: <58B04B47020000780013D936@prv-mh.provo.novell.com> <20170226234208.GA12547@bubble.grove.modra.org> <58B3E32902000078000F9844@prv-mh.provo.novell.com> <20170301024246.GG29416@bubble.grove.modra.org>
>>> 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.
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.
Jan
Jan