Re: ELF section identification and gld

["Jan Beulich" <JBeulich at novell dot com>]

>>> Ian Lance Taylor <ian@wasabisystems.com> 26.08.04 17:26:33 >>>
>"Jan Beulich" <JBeulich@novell.com> writes:
>
>> 1) Encountering two input sections with different allocation flags
but
>> identical names, ld renames the second one encountered by attaching
a
>> .<number> suffix. While the ELF spec isn't really explicit about
this,
>> it would have been my understanding that an ELF section is uniquely
>> identified by {name,type,flags} rather than just by its name. At
the
>> very least I'd expect ld to be able to optionally issue a warning to
the
>> user that this happened (especially when -r is in effect), because
(for
>> instance) linker scripts subsequently used to deal with the
resulting
>> output may deal only with the un-renamed sections unless the
>> programmer(s) learn(s) that it needs to deal with more.
>
>I did not know this.  I can't find it in the source code.  Where does
>it happen?  I agree that this behaviour is clearly wrong when using
>-r.

ld/emultempl/elf32.em, function gld${EMULATION_NAME}_place_orphan
calling bfd_get_unique_section_name.

>The GNU linker was written, before ELF existed, to base everything on
>section names.  The linker is always driven by a linker script, and
>the linker script assigns sections based on the name.  ELF has always
>been an uneasy fit in this regard.

As long as the sections are mentioned in the (perhaps built-in) script,
yes. For unmentioned sections, other logic is (and must be) used.

>Section names are not too important in ELF.  I think the linker
should
>ideally assign input sections to output sections based only on the
>section type and flags.

Without -r, that ought to work in most cases (though some grouping
based on the name is usually useful and often intended). With -r, the
name should be honored.

>To speak precisely, BFD does permit multiple sections with the same
>name.

Oh, right, through bfd_make_section_anyway.

>gas prefers to generate a single output section with a given
>name to accomodate existing code which uses .section with name, a
full
>type and flags, followed by subsequent uses of .section with just the
>name.

>Clearly gas should not silently replace the section type.  That
sounds
>like a bug.

It should be simple to come up with a patch for that. I'll find some
cycles...

>I think it would be reasonable for gas to create a new and different
>section when it sees a section declared with the same name but a
>different type and/or attributes.  That ought to be straightforward,
I
>hope.

Perhaps.

>> 3) Encountering a relocation for a section with the alloc flag set
and
>> targeting a section with the alloc flag clear is currently being
carried
>> out silently. However, it seems rather unlikely that this would
ever
>> result in a sensible executable, so I wonder what the reason is to
>> permit such a relocation and not even warn about it.
>
>Well, people can explicitly use NOLOAD in the linker script to
>indicate that they do not want a section to be loadable.  We assume
>that they know what they are doing.  Also, we generally permit
>relocations for non-ALLOC sections, because we want to permit
>relocations for debugging sections, in the hopes that the debugger
>will be able to use them in a sensible manner.
>
>There may well be a case here that merits a warning, but I don't
think
>a blanket warning would be right.

No, the case I'm talking about is the other way around. For debug info,
you have a relocation in a noalloc section targeting a symbol in an
alloc one. I want the blanket warning when a relocation for an alloc
section targets a noalloc one.

Jan