This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Gold] .ehframe problem with --sort-section=name. PR gold/17005
- From: Cary Coutant <ccoutant at google dot com>
- To: Alexander Ivchenko <aivchenk at gmail dot com>
- Cc: binutils <binutils at sourceware dot org>
- Date: Tue, 2 Sep 2014 15:51:53 -0700
- Subject: Re: [Gold] .ehframe problem with --sort-section=name. PR gold/17005
- Authentication-results: sourceware.org; auth=none
- References: <CACysShgPU_AintzEAxZBR5pWGARoeqvsD+6TnkP0k=FSWXHDdA at mail dot gmail dot com> <CAHACq4qddQx=iX2a8SNF+uqaPhRhZijcmf_FQAgY=vhez=EFOA at mail dot gmail dot com> <CACysShiVB+4MVcOZYedbqbOAD1wUuErwxjdee0o7a+S1gdTX=w at mail dot gmail dot com>
I've committed a fix for this issue:
https://sourceware.org/ml/binutils/2014-09/msg00011.html
Thanks for your investigation and proposed patches!
-cary
On Wed, Jul 2, 2014 at 6:18 AM, Alexander Ivchenko <aivchenk@gmail.com> wrote:
> I missed those discussions, thanks for pointing out. I'm looking
> forward to your fix then :)
> Please, also note, that PR17005 is present in 2.24.
>
> thanks,
> Alexander
>
> 2014-07-02 2:08 GMT+04:00 Cary Coutant <ccoutant@google.com>:
>>> The attached patch fixes PR17005 by providing the correct fde offsets
>>> to eh_frame_hdr and by
>>> fixing the assumption that in Eh_frame::set_final_data_size
>>> output_section is always equals to 0 in the beginning.
>>>
>>> Is it ok?
>>
>> The problem actually goes a bit deeper than this. The .eh_frame
>> contribution from crtendS.o should not be sorted to the beginning --
>> it's an end sentinel for the .eh_frame section, and needs to stay at
>> the end. The problem is that when sorting input sections by name, the
>> computed contents from optimizing the .eh_frame input sections is
>> added to the output section as an Output_section_data with no name,
>> and gets sorted to the end. I'm working on an alternate fix that will
>> preserve the proper order when sorting.
>>
>> Still, when there is an unoptimized section that comes, say, from
>> crt1.o or crtbeginS.o, it may be that the computed contents are placed
>> at a non-zero offset relative to the start of the output section, and
>> it is necessary to take that into account when adding the FDEs. See
>> also PR 14675 and the following discussion:
>>
>> https://sourceware.org/ml/binutils/2014-03/msg00310.html
>>
>> ...continuing into April...
>>
>> https://sourceware.org/ml/binutils/2014-04/msg00006.html
>>
>> -cary