RE: [arm-gnu] thumb code calling arm subroutine causes undefined insn exception

[Travis Geiselbrecht <Travis.Geiselbrecht@xxxxxxxx>]

Thumb encodes long branches as 2 instructions. The first instruction sets up the branch (I believe it puts part of the offset into LR), and the second one actually does it (merges LR with the rest of the offset). It was ARM's way of getting the relative branch space into a small instruction set. Since that's a little endian word, it's probably running 0xe9a4 first.

As far the blx, I think that is generated in ld, not gcc. I seem to remember there was some way to force ld to not use it, but I dont remember off the top of my head. I'd poke around on options there. Otherwise, this is where I'll have to bow out and let someone from CS handle it.
________________________________________
From: Andrew Kohlsmith (mailing lists account) [aklists@xxxxxxxxxx]
Sent: Sunday, April 25, 2010 18:32
To: arm-gnu@xxxxxxxxxxxxxxxx
Subject: Re: [arm-gnu] thumb code calling arm subroutine causes undefined insn exception

On Sunday 25 April 2010 06:39:31 pm Travis Geiselbrecht wrote:
> I might be wrong, but I'm pretty sure arm7tdmi does not support the blx
>  instruction. blx was added in armv5t instruction set. arm7tdmi is armv4.

Interesting.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0234b/i1010871.html

This is the link to the thumb instruction reference for ARM7TDMI-S, which is
the ARM variant in the LPC2103 CPU I'm using. I think you're on to something.
I see B, BL and BX, but not BLX.

However, the instruction is being encoded as 0xf000 0xe9a4. Figure 1.6 of that
URL shows that instruction format 19 is "long branch with link", which would
cause me to jump to 0, I think. Since the instruction at 0 is an ARM
instruction (it's the vector for the start of execution), that would certainly
cause the CPU to throw this exception.

> I'd try -mcpu=arm7tdmi or -march=armv4 to see if it'll stick to the right
>  instruction set. Thumb interworking on pre armv5s is pretty nasty though.
>  The lack of blx means it a lot of times have to jump through linker
>  generated shims and generally spend a lot more effort.

Since I am already using -mcpu=arm7tdmi, would this indicate that there is a
bug in the compiler wherein it is assuming that the BLX instruction exists on
the ARM7TDMI/TDMI-S?

I played around with -mcpu, -march, --fix-v4bx and --fix-v4bx-interwork, all
without success.  The latter two will remove bx instructions and use some shim
code to simulate it, but the blx instruction remains.

-A.