[Bug ld/10073] R_ARM_THM_PC8 Relocation Not Implemented in elf32-arm.c

[JayS at spectralogic dot com]

------- Additional Comments From JayS at spectralogic dot com  2009-05-04 22:05 
-------
Subject:  R_ARM_THM_PC8 Relocation Not Implemented in elf32-arm.c

Some thoughts:

I'm now linking an IAR object file that used to produce the same type of
errors that Owen had.  I made my own changes to the "case" handler that
seem logical to me, but I didn't try very hard to use the version that
Nick posted, so I can't say whether or not his version would work.

It looks like there were at least two distinct problems, and likely
more.  The first, of course, is that the linker didn't handle the
R_ARM_THM_PC8 case.  The second is the handling of overflows.  Also (as
mentioned above), I'm not sure that the way shifts were handled was
correct.

The IAR compiler apparently generates "signed" offsets in the
instructions, even though the offset used by ldr(3) is specified as
unsigned.  Their object files typically contain an offset of 0xff to
start with, and to which the relocation displacement is added.  This
always results in an overflow when interpreted by arm32-elf ld.  They
may do this for convenience, so that the relocation entry is relative to
the beginning of the instruction, not the pc register at the time of
execution.  I'm not sure what, if any, side effects may result from this
practice.  There may be none.  It still looks scary.

I think that they may also do this with other relocations.  I also get
overflow errors with the R_ARM_THM_CALL relocation.  I've disabled these
with a "#if 0" in my build, and it now builds code that looks like it
will run okay. 

The case statement for R_ARM_THM_PC8 relocation now reads:

    case R_ARM_THM_PC8:

        /* XXXjs 5/04/2009 Support thumb ldr(3) instruction, ignore
overflow. */
        {
                bfd_vma insn;
                bfd_signed_vma relocation;

                insn = bfd_get_16 (input_bfd, hit_data);

                if (globals->use_rel)
                        addend = (insn & 0x00ff) << 2;

                signed_addend = addend;

                relocation = value + signed_addend;
                relocation -= (input_section->output_section->vma
                                                +
input_section->output_offset
                                                + rel->r_offset);

                value = abs (relocation);

                insn = (insn & 0xff00) | (value >> 2);

                bfd_put_16 (input_bfd, insn, hit_data);

                return bfd_reloc_ok;
        }

Also, I disable testing and setting the overflow flag in the handler for
R_ARM_THM_XPC22, R_ARM_THM_CALL and R_ARM_THM_JUMP24.  I presume that
the errors that I've seen in R_ARM_THM_CALL are caused by the same
situation as R_ARM_THM_PC8, although I haven't put the effort into
dumping these out in detail.

Jay


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10073

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.