On Sunday 14 February 2010 08:41:00 Alexander Graf wrote: > Am Sun 14 Feb 2010 09:36:27 AM CET schrieb Rob Landley <r...@landley.net>: > > 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
