This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [GOLD] Handle merged input sections in Output_section::get_input_sections()
- From: Ian Lance Taylor <iant at google dot com>
- To: Doug Kwan (éæå) <dougkwan at google dot com>
- Cc: binutils <binutils at sourceware dot org>
- Date: Tue, 06 Apr 2010 20:49:25 -0700
- Subject: Re: [GOLD] Handle merged input sections in Output_section::get_input_sections()
- References: <s2n498552561004061801o71d1d2dfndc8ccd8d370b3de7@mail.gmail.com>
"Doug Kwan (éæå)" <dougkwan@google.com> writes:
> The final image does not contain the ELF header and the entry point is
> set to address 0. The input sections .rodata* are handled by gold as
> merged sections. They are not exported to the script by
> Output_section::get_input_sections() and are left at the beginning of
> the .text output section when normal input sections are removed. When
> the script re-inserts the input sections again, the merged input
> sections are now input beginning .text, where the entry point is
> located. That causes the output not bootable since the entry point
> contains a string instead of the first instruction.
>
> I am thinking about adding an get_input_sections method to the base
> class of merged sections. What do you think? We may optimize for
> speed by not exporting if the output section contains nothing but
> merged input section.
Interesting, this is the exact case I described in the comment saying
that with luck it would never matter.
I don't see how adding a get_input_sections method for merged sections
could do the right thing. The sections should still be merged, and I
don't see how that could happen if you pull out the input sections.
As far as I can see the only reasonable choice is to also add merge
sections to the list, and to arrange to handle merge sections in the
various callers.
Ian