Home Original page

ELF section identification and gld

Ian Lance Taylor ian@wasabisystems.com
Thu Aug 26 15:26:00 GMT 2004 
"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.

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.

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.

> 2) Related to the above, I wonder why bfd doesn't permit multiple
> sections with the same name in a single object (gas silently replaces
> the section type on an incompatible redeclaration, and ignores [with a
> warning] the change of the attributes, while ld as described above
> simply [and silently] renames the section); the ELF spec here does not
> say anything precluding multiple identically named sections in a single
> object.

To speak precisely, BFD does permit multiple sections with the same
name.  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.

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.

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

Ian
More information about the Binutils mailing list