[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: K. Richard Pixley
Subject: Re: [Qemu-devel] qemu-arm user mode
Date: Mon, 02 Oct 2006 14:11:00 -0700
User-agent: Thunderbird (X11/20060921)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]