This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: another round of h8300-rtems/coff problems
- To: joel dot sherrill at OARcorp dot com
- Subject: Re: another round of h8300-rtems/coff problems
- From: Nick Clifton <nickc at redhat dot com>
- Date: Thu, 2 Nov 2000 10:56:29 -0800
- CC: alan at linuxcare dot com dot au, binutils at sourceware dot cygnus dot com
Hi Joel,
: Should I leave the previous patch in as well?
No, I think it would be better not to have the workaround in. Instead
though, I would suggest trying out this patch with Alan's. It adds
code to detect the bad relocs and issue a suitable error message,
rather than core dumping.
Cheers
Nick
Index: bfd/reloc16.c
===================================================================
RCS file: /cvs/src//src/bfd/reloc16.c,v
retrieving revision 1.4
diff -p -r1.4 reloc16.c
*** reloc16.c 2000/07/03 17:49:37 1.4
--- reloc16.c 2000/11/02 18:54:49
*************** bfd_coff_reloc16_get_relocated_section_c
*** 299,306 ****
--- 299,321 ----
while (dst_address < link_order->size)
{
reloc = *parent;
+
if (reloc)
{
+ /* If the relocs are out of order, or at weird offsets, we
+ can get a situation where the reloc's address is before
+ the current source address. This is a bug in whatever
+ code generated the relocs. */
+ if (reloc->address < src_address)
+ {
+ /* xgettext:c-format */
+ _bfd_error_handler (_("Badly formatted relocs detected in '%s'"),
+ bfd_get_filename (input_bfd));
+
+ data = NULL;
+ break;
+ }
+
/* Note that the relaxing didn't tie up the addresses in the
relocation, so we use the original address to work out the
run of non-relocated data. */