This is the mail archive of the binutils@sourceware.org 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


> 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


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