This is the mail archive of the binutils@sources.redhat.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] |
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 of earch & Development joel@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Hunt le AL 35805 Support Available (256) 722-9985