This is the mail archive of the 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 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?

Note that gold has the behavior that I would expect, keep the sections
if there are symbols associated with it.

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

I am not sure the warning is spurious, it checks that a symbols value
refers to a specific location within a section using its section index
member, which seems to be how ELF intended the values to be used (except
of course where it says that there are other semantics for special
section indexes like abs, common and undef).



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