Re: ELF section identification and gld

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

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

Should I file a bug report? I haven't worked with the linker code a
lot, yet, so I don't feel like I could cheaply derive a fix here.

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

I saw it happen together with the other problem. The i386 linux build
currently may (configuration dependent) lead to ld -r renaming a section
with the alloc flag clear due to an identically named section in another
object with the alloc flag set. The linker script later dealing with
linking all the intermediately (ld -r) created objects into the final
executable only knows about the un-renamed section, and since the
renamed one is no-alloc, references from .text to the symbol(s) in this
section meet this criteria.
But I could certainly imagine other conditions leading to this that
could be safe-guarded against by emitting a warning (i.e. a symbol in a
debug info section incorrectly being referenced from a 'real' one, or
may be due to discarding an alloc section in the linker script [though I
don't know how exactly this works - it could either entirely discard the
section or simply make it no-alloc in the output, and in the former
there may already be a diagnostic]).

Jan