Re: PATCH: Check symbol type for symbol alias

[Richard Sandiford <richard at codesourcery dot com>]

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

Richard