Re: [RFC] PR ld/13621

[Alan Modra <amodra at gmail dot com>]

On Tue, Jan 31, 2012 at 07:00:02AM +1100, Richard Henderson wrote:
> 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.

I didn't say there was. ;)

> 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".

The choice of .data isn't arbitrary, but based on section flags as
well as adjacency.  The idea being to hopefully put symbols in a
section that belongs to the same segment (or overlay if such exists).
Using SHN_ABS loses this info.  That might matter for a hypothetical
system that dynamically relocates the data segment separately to the
code segment, something I looked at doing for powerpc64 at one stage.
It might also matter for analysis and optimisation tools like
FDPRpro.

Also, I dislike SHN_ABS symbols in executables and shared objects.
They're supposed to be absolute, yet glibc ld.so dynamically relocates
them, necessary for compatibility with ancient linkers and loaders..

> > 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.

I missed the alignment effect, but I still don't see any problem
whatsoever with a symbol "outside" of a section in an executable.  Is
there some reason other than an elflint warning that this matters?

-- 
Alan Modra
Australia Development Lab, IBM