This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Gold] .ehframe problem with --sort-section=name. PR gold/17005

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.


2014-07-02 2:08 GMT+04:00 Cary Coutant <>:
>> 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:
> ...continuing into April...
> -cary

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]