This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Question about ELF linker semantics
- To: mark@codesourcery.com
- Subject: Re: Question about ELF linker semantics
- From: Ian Lance Taylor <ian@zembu.com>
- Date: 15 Jun 1999 12:54:23 -0400
- CC: binutils@sourceware.cygnus.com
- References: <19990614181019N.mitchell@codesourcery.com>
From: mark@codesourcery.com
Date: Mon, 14 Jun 1999 18:10:19 -0700
When confronted with the following situation:
o environ is a weak symbol, equivalent to _environ
o _environ is defined in libc.so
o _environ is referenced in crt1.o
the IRIX6 linker does not emit an entry for "environ" in the dynamic
symbol table in the main executable. However, the GNU linker wants to
do so:
Incidentally, there are at least four different ELF linkers: SVR4,
Solaris, Irix, and GNU. The GNU linker tends to follow the Solaris
linker.
The reason is this code in elflink.h:elf_adjust_dynamic_symbol. If
this test holds, we bail and do not create a dynamic symbol table
entry. However, it does not hold in this case because
`h->weakdef->dynindx' is not -1. It probably doesn't matter, but I'm
curious as to what the GNU linker logic is supposed to be doing here?
There's an extended comment below this code that is perhaps trying to
explain the situation, but I couldn't make my (perhaps flawed)
understanding of that comment apply to this issue.
That comment isn't really trying to explain why weakdefs matter. How
about this comment?
/* 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. */
As I recall, the basic idea is that if the regular object refers to
environ, and environ is a weak symbol defined as _environ, we're going
to wind up generating a COPY reloc for environ. If we don't put
_environ in the dynamic symbol table, then environ in the executable
and _environ in the shared object will be different variables, which
obviously won't work.
Irix must be doing something different. What sort of dynamic reloc
does Irix generate to ensure that the environ in the executable and
the _environ in the library refer to the same address in memory?
Ian