more on h8300-rtems/coff core dump

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

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