This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ARM long branch stub: thumb
On Fri, 2009-02-20 at 16:54 +0100, Christophe LYON wrote:
> On 20.02.2009 16:23, Richard Earnshaw wrote:
> > On Fri, 2009-02-20 at 15:15 +0100, Christophe LYON wrote:
> >
> >> static const bfd_vma elf32_arm_stub_long_branch_v4t_thumb_arm[] =
> >> {
> >> - 0x4e03b540, /* push {r6, lr} */
> >> - /* ldr r6, [pc, #12] */
> >> - 0x473046fe, /* mov lr, pc */
> >> - /* bx r6 */
> >> - 0xe8bd4040, /* pop {r6, pc} */
> >> - 0xe12fff1e, /* bx lr */
> >> - 0x00000000, /* dcd R_ARM_ABS32(X) */
> >> + 0x46c04778, /* bx pc */
> >> + /* nop */
> >> + 0xe51ff004, /* ldr pc, [pc, #-4] */
> >> + 0x00000000, /* dcd R_ARM_ABS32(X) */
> >> };
> >
> > Unless I've missed a correction going on elsewhere, this isn't going to
> > work for BE-8 mode. The rules for manipulating thumb and ARM opcodes are
> > different (swap-16 and swap-32 respectively), and the code has to know
> > what instructions are at each address (the old code wouldn't have that
> > problem as it was all Thumb code).
>
> Damned!
>
> If I look at arm_build_one_stub, I can see that only put_arm_insn is
> use, whatever the stub being encoded. So there is a problem with any
> stub using thumb, isn't it?
Quite possibly. I don't like the way this code is storing thumb
instructions as 32-bit numbers anyway; but since that's a generic
problem with the code and not your patch I wasn't going to bring it up
at this point -- however, it looks like it might be necessary to address
that as a pre-requisite for all this anyway... :-)
R.