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: [RFC] PR ld/13621


On 01/31/2012 12:17 AM, Alan Modra wrote:
> The symbol is associated with some input file section.  This section
> gets mapped to some output file section, along with any symbols.  The
> output file section may not have the same name, for example, when a
> linker script maps your .tm_clone_table input section to .data output
> section. 

Misconception alert.

In this case there is no entry for .tm_clone_table in the linker script.
It gets placed after .data by normal orphan placement rules.
The final post-link size of .tm_clone_table is zero.
Zero sized output sections are removed by the linker.
The symbols are arbitrarily moved to .data simply because it is "nearby".

> I don't see why automatically mapping empty input sections
> to some other named section in a sensible manner should cause any more
> consternation than doing so via a linker script, except that in the
> past we've made separate output sections for empty input sections not
> mentioned in a linker script.  Current behaviour of not making empty
> orphan output sections has existed since 2005.

If we actually extended the range of .data to include the range of
.tm_clone_table, that would be fine too in my book.

But in the cases we're looking at, alignment constraints for 
.tm_clone_table have left padding between the end of .data and the
beginning of .tm_clone_table.  Which means that the symbols that
are associated with .data wind up outside of the section.


r~


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