I have now managed to run a null program and a helloworld, (both eabi,
linked statically, and without any thread calls), using the qemu-arm
user mode, both inside and outside of scratchbox. To do this with
qemu-0.8.2 I needed the following:
1) Paul's patch for NLS.
http://lists.gnu.org/archive/html/qemu-devel/2006-09/msg00194.html Note
that you will need to remove your object directory, reconfigure, and
rebuild after patching. The patch changes configuration data which will
not be updated from a simple rebuild so you will need to remove your
object and reconfigure before building again. I didn't notice and this
held me up for several days.
2) to build a qemu that can be debugged, you'll need to build it
statically. To do this, you can configure qemu using "--static".
3) qemu cannot be built with gcc-4, (due to a problem I don't
understand), nor with gcc-3 using -O0, (due to an apparent collision
between register allocation and inlining). You'll need to use a gcc-3,
with at least -O1 if you want to debug. I changed the -O values by
editing the Makefiles directly, but this change isn't really necessary
if you don't plan to debug qemu.
4) Configure using "--enable-uname-revision=2.6.16". Paul partially
explained this recently. Glibc, (the one your target program linked
against when it was compiled), runs a check to see what kernel version
it's running over. When qemu-user emulates this call, by default, it
asks the underlying host kernel what version the underlying host kernel
is and then tells gdb that the emulated kernel version is the same.
While there's an argument that this is reasonable, in the case of arm
eabi, it's a problem for many people. Since eabi support was only added
to the kernel in 2.6.16, earlier kernels can't handle eabi kernel
calls. Glibc knows this and will fail out if it believes itself to be
running on an older kernel. The fix, then, is to either run qemu-arm
with the command line option, "-r 2.6.16" or to configure using
"--enable-uname-revision=2.6.16" which will ask qemu to simply report
these version numbers rather than querying the underlying host kernel.
(Note: if your underlying (x86) host kernel happens to be 2.6.16 or
later, then you probably don't need this workaround.)
None of these are new issues or fixes. It just took me a few days to
collect, run into them, and sort through them all. So I'm posting my
results here.
--rich
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel