Re: PATCH: Check symbol type for symbol alias

["H.J. Lu" <hjl at lucon dot org>]

On Fri, Jul 20, 2007 at 02:06:31PM +0100, Richard Sandiford wrote:
> "H.J. Lu" <hjl@lucon.org> writes:
> > On Fri, Jul 20, 2007 at 10:12:42AM +0100, Richard Sandiford wrote:
> >> "H.J. Lu" <hjl@lucon.org> writes:
> >> > Here is a patch to add a testcase and check symbol type for symbol
> >> > alias.
> >> 
> >> In case anyone's in any doubt, this really doesn't fix my original
> >> problem.  Although the strong symbol in the test's shared library was
> >> defined by the linker script, that was mostly for test convenience.
> >> We can still have a situation in which an object symbol "bar" in a
> >> shared library is overridden by an assignment "PROVIDE (bar = .);" in
> >> the linker script of an object being linked against the shared library.
> >> (And as I said in the covering note, we do handle that situation
> >> correctly; we use relocations against the original weak symbol instead.)
> >> I can adjust the testcase in the obvious way if this patch goes in.
> >
> > The problem is linker creates a wrong symbol alias for a dynamic
> > object. We don't have a reliable way to tell if a symbol is an aliase
> > in a shared library. It can lead to many problems. Can we use
> > STT_SECTION for linker created symbols? Gabi says
> >
> > STT_SECTION
> >     The symbol is associated with a section. Symbol table entries of
> > this type exist primarily for relocation and normally have STB_LOCAL
> > binding.
> >
> > It doesn't forbid STB_GLOBAL binding. At least, we won't make a weak
> > symbol an alias of linker created symbols.
> 
> I think you're missing my point.  Please read what I said again.  You seem
> to be talking about cases where the alias should not be considered valid
> in isolation (i.e. by looking at the shared library and nothing else).
> The bug I'm fixing happens _regardless of whether the alias would
> normally be considered valid in isolation_.  Hence my comment about
> changing my testcase.  Although the original testcase did use a linker
> script to establish the alias, the test would still fail if that alias
> were established in the normal environ/__environ way.
> 
> In my example -- where the shared library is involved in a second link
> that redefines the strong symbol using a PROVIDE statement -- we _already_
> correctly determine that the alias is _not_ valid, because the PROVIDEd
> symbol overrides the shared library's symbol.  The problem is simply
> that we have a bogus assert along the way.  (Recall that this is a
> non-fatal assert.)  The code did not realise that a strongly-defined
> PROVIDE symbol would actually have type bfd_link_hash_undefined
> (rather than bfd_link_hash_defined or bfd_link_hash_defweak).
> 
> The bug I'm fixing is a corner case, and is simply an artifact of the
> way PROVIDE symbols are handled.
> 

We have 2 problems:

1. Linker may create wrong symbol alias.
2. Linker needs to handle the case where symbol alias in a shared
library is changed by linker created symbol.

For #2, I think linker should rediret symbol alias to the linker
created symbol. Does the linker do it correctly?


H.J.