[ARMedslack] Slackware 13.1 and forward is EABI...
m-lists at biscuit.org.uk
Wed Jul 21 07:11:59 UTC 2010
> 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.
In the build scripts this hasn't been set although it may be set in some
of the makefiles or configure scripts when they detect the ARM cpu.
> b) The kernel is emulating the "bx" instruction via an Undefined
> Instruction trap.
In the kernel there is this option:
This option preserves the old syscall interface along with the
new (ARM EABI) one. It also provides a compatibility layer to
intercept syscalls that have structure arguments which layout
in memory differs between the legacy ABI and the new ARM EABI
(only for non "thumb" binaries). This option adds a tiny
overhead to all syscalls and produces a slightly larger kernel.
If you know you'll be using only pure EABI user space then you
can say N here. If this option is not selected and you attempt
to execute a legacy ABI binary then the result will be
UNPREDICTABLE (in fact it can be predicted that it won't work
at all). If in doubt say Y.
I only just removed this from -current's kernel 2.6.35 package
(and forgot to put it into the changelog - it can go in the next "rc")
but I don't think this is what would help you, if it's in the kernel
John - if you need to get your project done soon, perhaps you can
just compile newer versions of particular software in 12.2?
If you look at the "arm/build" scripts in armedslack's source tree, it'll
give you an idea of what the dependencies are.
You could also get a SheevaPlug, put 12.2 on it and compile on there since
it has a 1GHz CPU and 512MB RAM.
More information about the ARMedslack