qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.


From: Alexander Graf
Subject: Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
Date: Mon, 15 Feb 2010 12:19:24 +0100

On 15.02.2010, at 12:10, Rob Landley wrote:

> On Sunday 14 February 2010 08:41:00 Alexander Graf wrote:
>> Am Sun 14 Feb 2010 09:36:27 AM CET schrieb Rob Landley <address@hidden>:
>>> On Thursday 11 February 2010 06:32:12 Alexander Graf wrote:
>>>> Rob Landley wrote:
>>>>> Static binaries that run under the Linux kernel don't run under
>>>>> qemu-ppc. For example, the prebuilt busybox binaries here:
>>>>> 
>>>>>  http://busybox.net/downloads/binaries/1.16.0/busybox-powerpc
>>>>> 
>>>>> Don't run under qemu-ppc, but runs just fine under qemu-system-ppc
>>>>> with the image at:
>>>>> 
>>>>> 
>>>>> http://impactlinux.com/fwl/downloads/binaries/system-image-powerpc.tar
>>>>> .bz 2
>>>>> 
>>>>> The reason is that the "powerpc spec" that qemu was written to is for
>>>>> AIX, not for Linux, and thus the register layout qemu application
>>>>> emulation provides for powerpc doesn't match what the kernel is
>>>>> actually doing.
>>>>> 
>>>>> For dynamically linked executables, the dynamic linker reorganizes the
>>>>> register contents to match the AIX spec from IBM, but statically
>>>>> linked binaries get what the kernel provides directly.  Thus binaries
>>>>> statically linked against uClibc won't run under qemu-ppc, but run
>>>>> under qemu-system-ppc just fine.
>>>>> 
>>>>> I tracked down this problem in 2007:
>>>>> 
>>>>>  http://landley.net/notes-2007.html#28-03-2007
>>>>> 
>>>>> And reported it on the list at the time:
>>>>> 
>>>>>  http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00713.html
>>>>>  http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00720.html
>>>>>  http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00315.html
>>>>> 
>>>>> However, the then-maintainer of powerpc believed nobody else ever had
>>>>> the right to touch "her code":
>>>>> 
>>>>>  http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00198.html
>>>>> 
>>>>> And I was unable to convince her that insisting reality change to
>>>>> match a spec which wasn't even for the right platform was not a useful
>>>>> approach. Thus the binary in the first link still won't run under
>>>>> qemu-ppc three years later, despite running fine under a real Linux
>>>>> kernel.
>>>> 
>>>> Patches are always welcome. The only thing you might want to make sure
>>>> is that dynamically linked binaries also still continue to work :-).
>>> 
>>> Attached.
>>> 
>>> This may help explain the issue:
>>> 
>>>  http://sources.redhat.com/ml/libc-alpha/2003-03/msg00272.html
>>> 
>>> It's not a question of dynamically linked Linux binaries.  They work
>>> just fine
>>> with either register layout.  The dynamic linker converts the Linux
>>> layout to the AIX layout, and is reentrant so it won't do it a second
>>> time if it's already been converted.
>>> 
>>> The problem is that BSD wants the AIX layout, and hence this comment
>>> in linux-
>>> user/elfload.c function init_thread():
>>> 
>>>    /* Note that isn't exactly what regular kernel does
>>>     * but this is what the ABI wants and is needed to allow
>>>     * execution of PPC BSD programs.
>>>     */
>>> 
>>> I.E. whoever wrote this already knows it's not what the Linux kernel is
>>> actually doing, and they're not doing it for Linux, they're doing it for
>>> BSD.
>>> 
>>> The fix is probably to add #ifdef CONFIG_BSD around the appropriate chunk
>>> of code.  Attached is a patch to do that (plus tweaks to make the "you
>>> have an unused variable, break the build!" logic shut up about it).
>>> 
>>> (Yes, I tested that a dynamically linked hello world still worked for
>>> me.)
>> 
>> I don't see why it would fail. The link above states that for
>> statically linked binaries, r1 points to all the variables. For
>> dynamically linked ones, you also get pointers in some regs.
>> 
>> So the only case I can imagine that this breaks anything is that
>> uClibc requires register state to be 0.
> 
> Yes, r3 (which is the exit code from the "exec" syscall, and thus 0 if it 
> worked).  In the BSD layout, it's argc (which can never be 0).
> 
>  http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00720.html

So what you really want is something like

#ifdef CONFIG_LINUX_USER
/* exec return value is always 0 */
env->gpr[3] = 0;
#endif

just after the #endif in your patch. If you had inlined your patch I could've 
commented it there.


Alex



reply via email to

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