linux-mips-fnet
[Top] [All Lists]

Re: MIPS/ELF linker

To: mark@codesourcery.com
Subject: Re: MIPS/ELF linker
From: Ian Lance Taylor <ian@zembu.com>
Date: 3 Aug 1999 12:28:59 -0400
Cc: ralf@uni-koblenz.de, ralf@gnu.org, binutils@sourceware.cygnus.com, thockin@cobaltnet.com, linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
In-reply-to: <19990801140327R.mitchell@codesourcery.com> (message from Mark Mitchell on Sun, 01 Aug 1999 14:03:27 -0700)
References: <19990731233150.Q12249@uni-koblenz.de> <19990731152842N.mitchell@codesourcery.com> <19990801012203.U12249@uni-koblenz.de> <19990801140327R.mitchell@codesourcery.com>
   From: Mark Mitchell <mark@codesourcery.com>
   Date: Sun, 01 Aug 1999 14:03:27 -0700

   Ian, I'd like your comments on a couple of other issues.  In auditing
   the current code vs. the pre-IRIX6 modifications I see that this hunk
   in the current code is not preserved:

                 else if (info->shared && !info->symbolic && 
!info->no_undefined)
                   relocation = 0;
                 else if (strcmp (h->root.root.string, "_DYNAMIC_LINK") == 0)
                   {
                     /* If this is a dynamic link, we should have created
                        a _DYNAMIC_LINK symbol in
                        mips_elf_create_dynamic_sections.  Otherwise, we
                        should define the symbol with a value of 0.
                        FIXME: It should probably get into the symbol
                        table somehow as well.  */
                     BFD_ASSERT (! info->shared);
                     BFD_ASSERT (bfd_get_section_by_name (output_bfd,
                                                          ".dynamic") == NULL);
                     relocation = 0;
                   }

   I don't see the point of the first line (in the context of the new
   code).  I think that when building a shared library, a relocation
   against an undefined symbol should simply be copied into the output
   file (adjust as necessary); there's no need to actually perform any
   relocation.  So, there's no need to give values to undefined symbols.
   Therefore, we don't call calculate_relocation in this case at all.  If
   you think that's wrong, please let me know.

When I read your paragraph above, it makes sense.  However, when I
look at the current code, I think that calculate_relocation will get
called for a reference to an undefined symbol from a shared library.

If you are proposing a different patch, to simply copy shared library
relocations against undefined symbols rather than to perform the
relocation, then I think that will indeed work correctly.  But note
that you do have to handle the info->symbolic and info->no_undefined
cases.  Something like the above code seems like a simple way to
handle all the cases.

   I'm also unsure about the _DYNAMIC_LINK bit.  On the one hand, it
   would seem that this should be defined in the linker-script if it's
   needed?  For instance, it would seem to be a bug if an IRIX6
   executable happened to use the symbol _DYNAMIC_LINK without a
   definition, but then linked successfully because we created this
   symbol "by magic".

Since this symbol is in the reserved name space, it's OK for the
linker to define it magically.  It's no more buggy for an executable
to use the symbol _DYNAMIC_LINK without a definition than it is for an
executable to use the symbol __program_header_table without a
definition.

This change was from Kazumoto Kojima; I assume that on some systems
_DYNAMIC_LINK is used to test whether the executable was linked
dynamically or not.  It's no less magic to define it in the linker
script than it is to define it in elf32-mips.c.  In this case, I don't
see how to define it correctly in the linker script.

   But, leaving that issue aside, we define this on all systems, in the
   non-shared case, in _bfd_mips_elf_create_dynamic_sections.  So, I
   don't think we need to handle this symbol specially when we perform
   relocations against it.  Do you agree?

_bfd_mips_elf_create_dynamic_sections is not called in all cases: it
is not called when doing a static link.  I believe that bit of code
got in there because some system expects _DYNAMIC_LINK to be defined
as 0 when doing a static link.  I think we do need to handle this one
way or another.

Ian

<Prev in Thread] Current Thread [Next in Thread>