|From:||K. Richard Pixley|
|Subject:||Re: [Qemu-devel] qemu-arm user mode|
|Date:||Mon, 02 Oct 2006 14:11:00 -0700|
|User-agent:||Thunderbird 188.8.131.52 (X11/20060921)|
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|