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

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.)

I didn't explicitly set it because they're initialized to zero in function 
main() on line 2654 of linux-user/main.c.  (Any regs we don't explicitly set 
to some other value start out zeroed in qemu.)

If you prefer to make the requirements explicit, that works too, but a comment 
might do just as well.  (I tend to prefer removing unnecessary work Linux 
doesn't need done, rather than adding extra code to undo the unnecessary work 
afterwards.  Force of habit from years on busybox and such.)

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]