qemu-devel
[Top][All Lists]
Advanced

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

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


From: Alexander Graf
Subject: [Qemu-devel] Re: qemu-ppc can't run static uClibc binaries.
Date: Tue, 16 Feb 2010 10:31:16 +0100

On 16.02.2010, at 01:52, Rob Landley wrote:

> On Monday 15 February 2010 07:08:33 Michael S. Tsirkin wrote:
>> On Mon, Feb 15, 2010 at 06:58:33AM -0600, Rob Landley wrote:
>>> On Monday 15 February 2010 05:19:24 Alexander Graf wrote:
>>>> On 15.02.2010, at 12:10, Rob Landley wrote:
>>>>> On Sunday 14 February 2010 08:41:00 Alexander Graf wrote:
>>>>>> 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.
>>> 
>>> Unfortunately kmail plays fast and loose with whitespace when I inline
>>> stuff. (Not always, but I can't tell by inspection when it's decided it
>>> was hungry for tabs or wanted to throw in that horrible UTF8 escaped
>>> whitespace.)
>> 
>> See Documentation/email-clients.txt under linux source tree.
> 
> I did.  That doesn't cover the different bugs in different versions, what 
> happens when you use kmail under xfce, and so on.  (It also doesn't mention 
> that you have to disable wordwrap for the entire message and hit return by 
> hand at the end of each line to get kmail not to wrap inline includes.  Or 
> that some versions of kmail embed NUL bytes into inline includes, for some 
> reason.)
> 
> I could make it work, just didn't know this list had a tropism for inline.  
> (Varies per list and I wander through a bunch of 'em.)  Over on the -hda sets 
> /dev/hdc topic I posted a patch inline which was ignored because the behavior 
> the Linux kernel has consistently had for the past decade or more isn't 
> considered especially important.  Thus I didn't think you were likely 
> following lkml tropes.

If swapping the parameter was the right solution I would've submitted a patch 
long ago :-). Unfortunately it's not as easy.
But the inlining is really only about simple commenting. It's a lot nicer to 
have context when you say "this doesn't make sense" or so :-).

Either way - it's good to see someone interested in the topic actually sending 
patches. Reviewing and commenting doesn't mean I don't like what you're doing. 
In this case it just means I'm pretty sure it doesn't solve the problem, but 
only the symptoms.


Alex



reply via email to

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