[ARMedslack] Slackware 13.1 and forward is EABI...
jawkins at armedslack.org
Tue Jul 20 22:45:49 UTC 2010
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.
> 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,
> 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 ;)
More information about the ARMedslack