Re: [RFC] PR ld/13621

[Alan Modra <amodra at gmail dot com>]

On Mon, Jan 30, 2012 at 09:28:40AM +0100, Mark Wielaard wrote:
> On Mon, Jan 30, 2012 at 01:56:26PM +1030, Alan Modra wrote:
> > On Mon, Jan 30, 2012 at 11:56:49AM +1100, Richard Henderson wrote:
> > > This PR is about elflint warning about symbols outside of the section
> > > with which they are associated.
> > 
> > Huh.  So what's wrong with a symbol belonging to a section but defined
> > outside of 0..section_size-1?  Particularly if it happens to be
> > defined at section_size.  That's quite a natural way to mark out the
> > bounds of an array.  I think this is just elflint being silly.
> 
> elflint allows the sillyness of marking out the bounds of the section.
> That is precisely what happens here, the symbol is used to mark the
> end of the section (section_size), but then the whole section that
> the symbol is associated with is removed.

There seems to be some misunderstanding about linker operation here,
and below when you talk about ld "tossing out" sections.

> So now the symbol is
> associated with some other random section, and points into some other
> one that now is associated with the address of the symbol.

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.

> In that
> case it seems natural to at least mark the symbol as being associated
> with SHN_ABS as Richard did, but it would be even better if ld didn't
> just toss out a section that has symbols associated with it, so that
> the address of the symbol at least matches up.

I'd rather you just fixed elflint's spurious warning.

-- 
Alan Modra
Australia Development Lab, IBM