linux-mips
[Top] [All Lists]

Re: an ld problem? - possibly fixed..

To: Tim Hockin <thockin@cobaltnet.com>
Subject: Re: an ld problem? - possibly fixed..
From: Ralf Baechle <ralf@uni-koblenz.de>
Date: Fri, 30 Jul 1999 23:01:27 +0200
Cc: linux@cthulhu.engr.sgi.com
In-reply-to: <37A137F7.91B5AC4A@cobaltnet.com>; from Tim Hockin on Thu, Jul 29, 1999 at 10:28:23PM -0700
References: <379FBBFE.FB8C1734@cobaltnet.com> <19990729153427.E4730@uni-koblenz.de> <37A137F7.91B5AC4A@cobaltnet.com>
Sender: owner-linux@cthulhu.engr.sgi.com
On Thu, Jul 29, 1999 at 10:28:23PM -0700, Tim Hockin wrote:

> Ralf Baechle wrote:
> 
> > just in case if you manage to fix this one please drop me a note.
> 
> I'm calling in for help on the solution now.
> 
> The problem occurs when a segment is found that is not a known name, libbfd
> abort()s in mips_elf_relocate_section().  In the case of the egcs libstdc++
> link the segments in question are : ".dtors" and ".gcc_except_table".  I 
> assume
> since .dtors is trouble, so will .ctors be.
> 
> If I add .dtors and .gcc_except_table to mips_elf_dynsym_sec_names[] in
> ${binutils_src_path}/bfd/elf32-mips.c and rebuild libbfd - ld no longer gets 
> an
> abort() when compiling the file in question.  I'm pretty sure this is NOT the
> right solution.  There is also a table of sections in
> ${binutils_src_path}/bfd/syms.c.  What is the "right" solution, and what other
> sections can exist that bfd doesn't know about?
> 
> Someone with a bit more experience inside libbfd - please help? :)

I think that already having a list of section names for that purpose is
an error.  Current libbfd doesn't rely on it anymore.  Guess it's time
to bite the bullet and try to rebuild the entire system just using
binutils-current from Cygnus CVS.  Binutils, born to be fixed ...

There is another bug in libbfd where section->owner is NULL which makes
the linker do the segv boogy.  It's being trigger by the linker options
``-lm -lieee'' when linking arbitrary code using the native linker.  I
didn't research that case further because I got detracted into GDB
debugging when GDB started crashing while I was investigating that case ...

  Ralf

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