Re: [Qemu-devel] qemu-arm user mode

["K. Richard Pixley" <rich.pixley@palmsource.com>]

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