Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
On Tue, Feb 16, 2010 at 08:21:45AM +, Stuart Brady wrote: On Mon, Feb 15, 2010 at 12:19:24PM +0100, Alexander Graf wrote: 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. I've clearly misunderstood something, but isn't CONFIG_LINUX_USER always going to be defined when building linux-user/elfload.c, and doesn't CONFIG_BSD relate to the host that you're building for, not the target? Yes, CONFIG_LINUX_USER will always be defined in linux-user/elfload.c, while CONFIG_BSD_USER will always be defined in bsd-user/elfload.c. The same way using CONFIG_BSD in linux-user/elfload.c doesn't make sense, as this code will never been compiled. I can't remember whether Jocelyn was interested in running BSD binaries under Linux or under BSD. The former seems reasonable, although even if that did work for PPC at one point, I doubt that's still the case... That's sound strange, if you do that I think you will need to use the bsd-user code, not the linux-user code. I have to say I don't really understand the reason why this BSD code is there. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
On Mon, Feb 15, 2010 at 12:19:24PM +0100, Alexander Graf wrote: 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. I've clearly misunderstood something, but isn't CONFIG_LINUX_USER always going to be defined when building linux-user/elfload.c, and doesn't CONFIG_BSD relate to the host that you're building for, not the target? I can't remember whether Jocelyn was interested in running BSD binaries under Linux or under BSD. The former seems reasonable, although even if that did work for PPC at one point, I doubt that's still the case... Cheers, -- Stuart Brady
Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
On Monday 15 February 2010 07:01:02 Alexander Graf wrote: On 15.02.2010, at 13:58, 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.) git-send-mail is your friend :-). No git command is my friend. The user interface of that monstrosity should be strikecondemned/strike banished with full bell book and dribbly candles. And I dunno how it would interface with kmail. (No other program on my laptop has the ssh tunnel to my mail server set up so it can send anything.) But out of curiosity... land...@driftwood:~$ git send-mail git: 'send-mail' is not a git-command. See 'git --help'. land...@driftwood:~$ git-send-mail bash: git-send-mail: command not found land...@driftwood:~$ git send mail git: 'send' is not a git-command. See 'git --help'. Since it's unlikely that this could send a patch I haven't checked into git (and I generally treat git as a read-only resource), learning more about it goes on the todo list I expect. 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.) So it should work already? *shrug* It doesn't. Let's see, one of the lines I #ifdefed out (line 535-ish of linux- user/elfload.c) is: get_user_ual(_regs-gpr[3], pos); Rummage, rummage... get_user_ual() is a wrapper for get_user() which is a wrapper for __get_user() which assigns to its first argument. So yeah, that's setting _regs-gpr[3] to a nonzero value. I don't know if that's the _only_ problem the block of code I #ifdefed out was causing, but in general that whole section is specifically for BSD, and makes the behavior diverge from that of the Linux kernel. 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.) Well, I personally prefer to always use the same code paths whenever possible. That makes the code less prone to failure in odd configurations. And we have a lot of different combinations of those in Qemu. Not all Linux binaries are going to run on BSD. This is a case where the behavior of the two honestly diverges, and existing code depends on the actual linux-kernel behavior. But this is Riku's call. He's the linux-user maintainer. Hi Riku! /me makes puppy eyes at Riku. Alex Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds
Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
On 16.02.2010, at 19:31, Rob Landley wrote: On Monday 15 February 2010 07:01:02 Alexander Graf wrote: On 15.02.2010, at 13:58, 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.) git-send-mail is your friend :-). No git command is my friend. The user interface of that monstrosity should be strikecondemned/strike banished with full bell book and dribbly candles. And I dunno how it would interface with kmail. (No other program on my laptop has the ssh tunnel to my mail server set up so it can send anything.) But out of curiosity... land...@driftwood:~$ git send-mail git: 'send-mail' is not a git-command. See 'git --help'. land...@driftwood:~$ git-send-mail bash: git-send-mail: command not found land...@driftwood:~$ git send mail git: 'send' is not a git-command. See 'git --help'. Since it's unlikely that this could send a patch I haven't checked into git (and I generally treat git as a read-only resource), learning more about it goes on the todo list I expect. 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.) So it should work already? *shrug* It doesn't. Let's see, one of the lines I #ifdefed out (line 535-ish of linux- user/elfload.c) is: get_user_ual(_regs-gpr[3], pos); Rummage, rummage... get_user_ual() is a wrapper for get_user() which is a wrapper for __get_user() which assigns to its first argument. So yeah, that's setting _regs-gpr[3] to a nonzero value. Well I was wondering on the order of execution. If main() already sets the GPRs to 0 it should be 0. I assume the elf reading code comes after that? If so, your patch looks correct. Alex
Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
On Tuesday 16 February 2010 12:36:15 Alexander Graf wrote: On 16.02.2010, at 19:31, Rob Landley wrote: Let's see, one of the lines I #ifdefed out (line 535-ish of linux- user/elfload.c) is: get_user_ual(_regs-gpr[3], pos); Rummage, rummage... get_user_ual() is a wrapper for get_user() which is a wrapper for __get_user() which assigns to its first argument. So yeah, that's setting _regs-gpr[3] to a nonzero value. Well I was wondering on the order of execution. If main() already sets the GPRs to 0 it should be 0. I assume the elf reading code comes after that? If so, your patch looks correct. The main() code memsets all the registers to zero when the array is allocated, then passes the register array as the first argument to the target-specific init_thread(), which can initialize them to other values. So yeah, main() calls the elf reading code after the memset. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds
Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
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
Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
On 15.02.2010, at 12:10, Rob Landley wrote: 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 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. Alex
Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
On 15.02.2010, at 13:58, 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.) git-send-mail is your friend :-). 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.) So it should work already? 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.) Well, I personally prefer to always use the same code paths whenever possible. That makes the code less prone to failure in odd configurations. And we have a lot of different combinations of those in Qemu. But this is Riku's call. He's the linux-user maintainer. Alex
Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
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.)
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 1d5f651..eaabdac 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -513,12 +513,11 @@ do {\
static inline void init_thread(struct target_pt_regs *_regs, struct image_info *infop)
{
abi_ulong pos = infop-start_stack;
-abi_ulong tmp;
#if defined(TARGET_PPC64) !defined(TARGET_ABI32)
abi_ulong entry, toc;
#endif
-_regs-gpr[1] = infop-start_stack;
+_regs-gpr[1] = pos;
#if defined(TARGET_PPC64) !defined(TARGET_ABI32)
entry = ldq_raw(infop-entry) + infop-load_addr;
toc = ldq_raw(infop-entry + 8) + infop-load_addr;
@@ -526,6 +525,8 @@ static inline void init_thread(struct target_pt_regs *_regs, struct image_info *
infop-entry = entry;
#endif
_regs-nip = infop-entry;
+
+#if defined(CONFIG_BSD)
/* 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.
@@ -534,9 +535,13 @@ static inline void init_thread(struct target_pt_regs *_regs, struct image_info *
get_user_ual(_regs-gpr[3], pos);
pos += sizeof(abi_ulong);
_regs-gpr[4] = pos;
-for (tmp = 1; tmp != 0; pos += sizeof(abi_ulong))
-tmp = ldl(pos);
+for (;;) {
+abi_ulong tmp = pos;
+pos += sizeof(abi_ulong);
+if (!ldl(tmp)) break;
+}
_regs-gpr[5] = pos;
+#endif
}
/* See linux kernel: arch/powerpc/include/asm/elf.h. */
Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
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. Alex
[Qemu-devel] qemu-ppc can't run static uClibc binaries.
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.bz2 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. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds
Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.
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.bz2 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 :-). Alex
