Re: Fix assertion failure on aliases of dynamic weak symbols

[Ian Lance Taylor <iant@google.com>]

"H.J. Lu" <hjl@lucon.org> writes:

> That piece of code was added by Richard on May 3, 1999 with
> comments:

Richard added the entire binutils world on May 3, 1999.  I actually
wrote that code originally, in the Cygnus repository.

>   /* Now set the weakdefs field correctly for all the weak defined
>      symbols we found.  The only way to do this is to search all the
>      symbols.  Since we only need the information for non functions in
>      dynamic objects, that's the only time we actually put anything on
>      the list WEAKS.  We need this information so that if a regular
>      object refers to a symbol defined weakly in a dynamic object, the
>      real symbol in the dynamic object is also put in the dynamic
>      symbols; we also must arrange for both symbols to point to the
>      same memory location.  We could handle the general case of symbol
>      aliasing, but a general symbol alias can only be generated in
>      assembler code, handling it correctly would be very time
>      consuming, and other ELF linkers don't handle general aliasing
>      either.  */
> 
> It no longer applies today since there is no difference between
> weak def and strong def in a shared library. Richard, do you
> remember if there is a testcase for your change? Can we remove
> the whole u.weakdef thing now? It will make linker simpler and
> faster.

The fact that there is no difference between weak defs and strong defs
is irrelevant here.  What is happening here is that the library
defines "environ" as a weak symbol.  "environ" is a weak alias for the
real symbol named "__environ".  The program refers to "environ".
Nothing outside the shared library refers to "__environ".  The shared
library refers only to "__environ", never to "environ" (other than
defining it as a weak alias).  If we only put "environ" in the dynamic
symbol table, then the dynamic linker will update the GOT entry for
"environ" so that all references to "environ" refer to the copy in the
main program.  If we don't put "__environ" in the dynamic symbol
table, then the GOT entry for "__environ" will continue to refer to
the copy in the dynamic object's data segment.  The effect is that the
dynamic object will set "__environ" at run time, and the program will
happily look at the uninitialized variable "environ".

Ian