an ld problem?

an ld problem?

[Tim Hockin]

I'm trying to compile egcs-1.0.2-9 on a Cobalt (mipsel) box.  During the
libstdc++ build I we have the following:


compile string:
/home/src/redhat/BUILD/egcs-1.0.2/obj-mipsel-linux/gcc/xgcc
-B/home/src/redhat/BUILD/egcs-1.0.2/obj-mipsel-linux/gcc/ -O2
-fno-implicit-templates -Wl,-soname,libstdc++.so.2.8 -shared -o
libstdc++.so.2.8.0 `cat piclist` -lm

result:
collect2: ld terminated with signal 6 [Aborted], core dumped

I have traced it through ld to this point: (elf32-mips.c : line 1526)

                          asection *osec;

                          osec = sec->output_section;
                          indx = elf_section_data (osec)->dynindx;
                          if (indx == 0)
                            abort ();

where it aborts.  I am a bit bewildered.  Anyone have any ideas to
offer?  Help?

Tim

Re: an ld problem?

[Ralf Baechle]

On Wed, Jul 28, 1999 at 07:27:10PM -0700, Tim Hockin wrote:

> where it aborts.  I am a bit bewildered.  Anyone have any ideas to
> offer?  Help?

I cheated; we currently ship only with a static libstdc++.  We've got
a fix for one of the many libbfd coredump bugs in elf32-mips.c in
our patchset of ftp.linux.sgi.com.  I think it won't cure this
particular case, however.

  Ralf

Re: an ld problem? - possibly fixed..

[Tim Hockin]

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? :)

Tim

Re: an ld problem? - possibly fixed..

[Ralf Baechle]

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