[RFC] PR ld/13621

[Alan Modra]

On Mon, Jan 30, 2012 at 03:13:57PM +0100, Mark Wielaard wrote:
> On Mon, 2012-01-30 at 23:47 +1030, 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.  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.
> 
> I might be missing something, but according to elf/gabi associating the
> symbol, through the section index member, makes sure that the symbol's
> value refers to a specific location within that section, so that
> references to the symbol continue to point to the same location in the
> program. So, it seems to me you cannot just remove a section which has a
> symbol associated with it, because if you do you can no longer make sure
> the value will refer to the right location. So two different symbols
> associated with different sections would have values that pointed to
> different locations in the program, which I don't see how you guarantee
> with the current behavior. Maybe I am just missing the (sensible) manner
> how ld does the automatic mapping of empty sections?

The point is that *none* of the input sections are really kept.
Instead, input sections are *mapped* to output sections.  You'll see
that global symbols within the input sections have their section index
translated to the appropriate output section index, often a different
index to that in the input file.

Internally, GNU ld does create output sections and later remove them,
but this is just an implementation detail.  ld could, if it were made
a little more clever, not create these sections in the first place.

As far as symbols go, the ELF spec says that st_value for (non-common)
symbols in relocatable object files is an offset from the beginning of
a section.  There is nothing to say that values should be within the
section bounds.  In an executable or shared object the ELF spec
says of symbol values that "the section number is irrelevant", since
st_value is no longer a section offset but a virtual memory address.
(That doesn't mean to say the section is totally irrelevant, just that
it is irrelevant so far as the value is concerned.)  So that's why I
claim that the elflint warning is a little silly.

-- 
Alan Modra
Australia Development Lab, IBM