This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Question about ELF linker semantics


   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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]