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, 1 Jul 2014 15:08:30 -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>
> 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