Re: ELF section identification and gld

[Ian Lance Taylor <ian at wasabisystems dot com>]

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

Oh yeah.  I think this code may be buggy.  It was intended to handle
the case in which an input section was orphaned even though the output
section exists.  That can happen if, for example, the output section
is created by the linker for whatever reason.

However, the way the code is written, if two orphaned input sections
have the same name, the second one will get a unique output section
name.  Really they should both go into the same output section (if the
flags are compatible).  That is, the test should not be unconditional
on whether an output section exists with the same name.  Perhaps we
should test SEC_LINKER_CREATED, if that is used consistently.

You are correct that in the case of incompatible flags, or
SEC_LINKER_CREATED, the linker should arguably create a new section
with the same name and the appropriate flags.  This is where we may
run into trouble with the way that linker scripts base everything
purely on the section name.  On the other hand, it may work fine, as
place_orphan sets up the appropriate links directly.

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

I think I see what you mean.  I am slightly confused by your use of
the word "targets."  I think I would say "when a relocation in an
alloc section refers to a symbol which is defined in a non-alloc
section."  I agree that that case does not make sense.  When does it
happen?

Ian