[ARMedslack] Slackware 13.1 and forward is EABI...

[Jim Hawkins]

On Tue, 20 Jul 2010, Stuart Winter wrote:

> I am not a toolchain or architecture wizard, so I might be wrong here; 
> but I think it's not just compiling it for armv4t that matters (compared 
> with -march=armv4 which is what AS 12.2 used).

I have to admit to having no experience of Thumb, but I would imagine 
you'd have to explicitly tell the compiler to target Thumb instead of 
normal 32-bit ARM instructions by specifying -mthumb or similar to gcc. 
Assuming AS isn't compiled in such a way, the only problem would be EABI's 
use of the "bx" instruction to return from function calls.

> %{mcpu=arm8|mcpu=arm810|mcpu=strongarm*|march=armv4:--fix-v4bx}
> [...snip...]
> which you can see in gcc's specs for EABI, that this is present.
> This *may* be why the binaries from -current are working on that CPU.

The specs show that --fix-v4bx is only passed to the assembler for the 
ARMv4 ISA and specific v4 CPUs.

> If Jim is reading,

Hello :)

> he can probably tell for sure since he's our resident ARM assembler 
> expert :-)

Ok, so looking at an assembler dump of a binary on your -current box, you 
can clearly see it's riddled with "bx lr" instructions:

root at zaden:~# objdump -d /bin/bash | grep bx | head
   1df70:	e12fff1e 	bx	lr
   1e8f0:	e12fff1e 	bx	lr
   1e910:	e12fff1e 	bx	lr
   1e938:	112fff13 	bxne	r3
   1e940:	e12fff1e 	bx	lr
   1e964:	e12fff1e 	bx	lr
   1eb04:	e12fff1e 	bx	lr
   1eb3c:	e12fff1e 	bx	lr
   1eb6c:	e12fff1e 	bx	lr
   1eb90:	e12fff1e 	bx	lr

These are also not preceeded by any special instruction sequences to 
detect returning to non-Thumb mode and instead issuing the ARMv4 
compatible "mov pc, lr".

Obviously that leaves the question of how this is working for John if his 
platform supposedly doesn't support Thumb. I would guess that either:

a) The CPU doesn't support Thumb, but partially implements the "bx" 
instruction insofar as it allows branching to non-Thumb destination 
addresses for the purposes of working with the EABI in non-Thumb mode.

b) The kernel is emulating the "bx" instruction via an Undefined 
Instruction trap. I couldn't see any evidence of this from a quick look 
through the vanilla kernel source tree, but perhaps he's using a patched 
vendor-supplied kernel. If this is the case then it will probably cause 
most code to run slower than if it was compiled for the old ABI. I guess 
the kernel could also be dynamically patching running code so that it only 
suffers a performance hit the first time the instruction is executed, but 
that's not a perfect solution.

c) He's actually running AS 12.2 binaries ;)

Cheers,

Jim