more on h8300-rtems/coff core dump
Joel Sherrill
joel.sherrill@OARcorp.com
Mon Oct 30 07:05:00 GMT 2000
I now have more information. I now know what triggers this
problem but have no clue how to fix it. Thanks to Alan
Modra for giving me a hint on how to track it down this far.
There is something fundamentally broken with "ld -r" on the
h8300-rtems (aka h8300-coff) target in binutils 2.10. I could
decipher enough to realize what was happening at the time of
the core dump. :)
There is a loop around line 321 of bfd/reloc16.c in the routine
bfd_coff_reloc16_get_relocated_section_contents(). Somehow
"run" is set to 4294967088 (0xffffff30) for this case.
Doing a "p *input_bfd" shows me that the file being processed
at this point is a .rel (.o's collected with ld -r).
When I explicitly linked in the individual .o's before
referencing the library, it worked. The -r must be confusing
things.
I have reduced the test case to a handful of .o's and the
.rel to produce the following:
$ h8300-rtems-ld -m h8300h cpu.o cpu_asm.o
### works gives undefined references
$ h8300-rtems-ld -m h8300h rtems-cpu.rel
rtems-cpu.rel: could not read symbols: File format not recognized
$ h8300-rtems-ld -m h8300h start.o rtems-cpu.rel
### some undefined references, then core dumps.
Just to eliminate mistakes in the makefile's I created a
new rtems-cpu.rel like this:
h8300-rtems-ld -m h8300h cpu.o cpu_asm.o -r -o rtems-cpu.rel
and repeated things with the same results.
I would really appreciate someone more knowledgeable than
myself investigating this. The 3 .o's in the above example
are a total of 10K so it is not a big deal to send them.
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the Binutils
mailing list