core dump in h8300-rtems-ld (coff) (binutils 2.10)

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Hi,

The RTEMS h8300 port is triggering a core dump in ld.  The
actual invocation of ld is hidden underneath collect2 which
is invoked by gcc.  Here is the collect2 command line:

bash$ /opt/rtems/lib/gcc-lib/h8300-rtems/2.95.2/collect2 -m h8300h -dc
-dp -N -e _start -o o-optimize/hello.exe
../../../../../../h8sim/lib/start.o -L ../../../../../../h8sim/lib
-L../../../../../../h8sim/lib
-L/opt/rtems/lib/gcc-lib/h8300-rtems/2.95.2/h8300h/int32
-L/opt/rtems/lib/gcc-lib/h8300-rtems/2.95.2
-L/opt/rtems/h8300-rtems/lib/h8300h/int32 -L/opt/rtems/h8300-rtems/lib
o-optimize/init.o -lgcc --start-group -lrtemsall -lc -lgcc --end-group
-T ../../../../../../h8sim/lib/linkcmds -lgcc
collect2: ld terminated with signal 11 [Segmentation fault]

When I back trace in gdb on the core, I see this:

bash$ gdb /opt/rtems/bin/h8300-rtems-ld core
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/opt/rtems/bin/h8300-rtems-ld -m h8300h -dc -dp
-N -e _start -o o-optimize/hell'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libNoVersion.so.1...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x806a431 in bfd_coff_reloc16_get_relocated_section_contents (
    in_abfd=0x808c7a8, link_info=0x80863f4, link_order=0x808d30c, 
    data=0x8d967d8 "\001", relocateable=false, symbols=0x80cae88)
    at ../../binutils-2.10/bfd/reloc16.c:321
321	../../binutils-2.10/bfd/reloc16.c: No such file or directory.
(gdb) bt
#0  0x806a431 in bfd_coff_reloc16_get_relocated_section_contents (
    in_abfd=0x808c7a8, link_info=0x80863f4, link_order=0x808d30c, 
    data=0x8d967d8 "\001", relocateable=false, symbols=0x80cae88)
    at ../../binutils-2.10/bfd/reloc16.c:321
#1  0x805e020 in bfd_get_relocated_section_contents (abfd=0x808c7a8, 
    link_info=0x80863f4, link_order=0x808d30c, data=0x8d967d8 "\001", 
    relocateable=false, symbols=0x80cae88)
    at ../../binutils-2.10/bfd/bfd.c:1135
#2  0x8063077 in default_indirect_link_order (output_bfd=0x808c7a8, 
    info=0x80863f4, output_section=0x808cab4, link_order=0x808d30c, 
    generic_linker=true) at ../../binutils-2.10/bfd/linker.c:2743
#3  0x806253f in _bfd_generic_final_link (abfd=0x808c7a8,
info=0x80863f4)
    at ../../binutils-2.10/bfd/linker.c:2047
#4  0x8057a8e in ldwrite () at ../../binutils-2.10/ld/ldwrite.c:519
#5  0x805567a in main (argc=28, argv=0xbffff714)
    at ../../binutils-2.10/ld/ldmain.c:367
(gdb) 

There is definitely something wrong with objects linked with "-r"
as well on the h8300.  There are a few of these in RTEMS and when
I include them in links, we see errors regarding multiple definitions
of __[cd]tors and __[cd]tors_end.  Looking at them in more detail,
I see that before the "-r" ld, tehey do not include references to 
__ctors, etc but the ".rel" version has these addition entries 
according to nm:

00000178 ? ___ctors
00000178 ? ___ctors_end
00000178 ? ___dtors
00000178 ? ___dtors_end

When I do an objdump -h on the .o vs .rel, I see that the .tors
section has been added to the .rel.  

I have no idea what should be happening but would be happy to help 
track it down given some advice.

Thanks.

-- 
Joel Sherrill, Ph.D.             Director ofearch & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntle AL 35805
   Support Available             (256) 722-9985