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 05:10:21 -0600
User-agent: KMail/1.11.2 (Linux/2.6.28-17-generic; KDE/4.2.2; x86_64; ; )

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

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]