Re: weak defined symbols in shared object lost by dynamic link?

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Aug 09, 2006 at 01:35:36PM -0700, Stuart Balfour wrote:
> Daniel,
> 
> I'm just catching up in HJ's thread.  PROVIDE_HIDDEN might be the answer 
> going forward, but I'm reluctant to add feature content to binutils-2.14
> or even binutils-2.15.  I have three BFD ASSERTS and an application crash.
> So I must answer the question, what did they (developers) do wrong, or
> what do I (binutils maintainer) fix?

As a general rule from my experience maintaining existing branches,
backporting things - even features - from mainline binutils is a much
better choice than inventing your own solutions.

> Make the argument that we must override weak defined and (possibly)
> referenced symbols in shared objects with linker script PROVIDEd symbols.
> PROVIDE is itself an escape mechanism (...don't forget these, but in case
> you do, here they are... hope and pray).

That's just not an accurate summary of what PROVIDE is for.  It's
mostly to avoid cluttering the symbol table and namespace if you don't
need the resulting symbols.

> Can you give me an example of a
> bad thing that happens?  We made shared-object PROVIDEd symbols special,
> with an attribute that's neither their binding nor visibility, so that we
> tend to lose them along the way.  That is a bit of complexity, because the
> effect wouldn't happen if I had defined the symbols programatically in the
> shared object.  I'm groping here.

Yes, you're groping.  That's exactly why I recommend leaving these
murky areas alone.  Using hidden symbols in the shared library has
clear and _well-understood_ semantics.  I think you've wandered
far away from your original problem at this point.

Looking at your original case, the symbols are defined in the shared
library with global visibility.  They're PROVIDE'd in the executable. 
It doesn't matter whether we honor them or ignore them; you've
already created the problem.

If you ignore them, the executable will ask for &_etext and get its own
text end, but the shared library will get the executable's.  If you
honor them, the executable will ask for &_etext and get the shared
library's.  _etext is inherently a per-object property, as are most
other commonly provided symbols; they should be provided as hidden,
so that they are bound to the object to which they refer and only
visible to that object.

-- 
Daniel Jacobowitz
CodeSourcery