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: Rob Landley
Subject: [Qemu-devel] Re: qemu-ppc can't run static uClibc binaries.
Date: Mon, 15 Feb 2010 18:52:58 -0600
User-agent: KMail/1.11.2 (Linux/2.6.28-17-generic; KDE/4.2.2; x86_64; ; )

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.

*shrug*  Now I know...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds




reply via email to

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