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
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 wrappe
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
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 c
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
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 re
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 (w
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 :
>>> On Thursday 11 February 2010 06:32:12 Alexander Graf wrote:
Rob Landley wrote:
> Static binaries that run under the Linu
On Sunday 14 February 2010 08:41:00 Alexander Graf wrote:
> Am Sun 14 Feb 2010 09:36:27 AM CET schrieb Rob Landley :
> > 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 ex
Am Sun 14 Feb 2010 09:36:27 AM CET schrieb Rob Landley :
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/downlo
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 r
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
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.
13 matches
Mail list logo
