qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug] qemu-sparc64 broken


From: Peter Maydell
Subject: Re: [Qemu-devel] [Bug] qemu-sparc64 broken
Date: Thu, 5 Sep 2013 22:32:02 +0100

On 5 September 2013 21:35, Stefan Weil <address@hidden> wrote:
> Here is the result of running Debian's busybox-static for sparc64:
>
> $ sparc64-linux-user/qemu-sparc64 /usr/gnemul/qemu-sparc64/bin/busybox
> ls -l block.c
> ?rwxr-x--T    1 stefan   root     1378329541 Jan  1  1970 block.c
>
> It's obviously wrong. All other user emulations return the correct result:

SPARC linux-user emulation has been pretty badly broken
and obviously unused (except probably for being able to
run gcc test suite code) for some time (if it ever worked at all);
I fixed a pretty obvious problem in commit 82f05b69e6
which meant bash couldn't run any programs, for instance.

> $ busybox ls -l block.c
> -rw-r--r--    1 stefan   stefan      131462 Sep  3 21:13 block.c

Try checking the target_stat and target_stat64 struct
definitions in linux-user/syscall_defs.h against the kernel's
versions; there's probably a mismatch.
http://lxr.linux.no/#linux+v3.11/arch/sparc/include/uapi/asm/stat.h#L8
The most obvious error is that st_nlink should be a short,
not an int. One of the others must be wrong too, though,
because alignment padding would cancel that out. You
need to chase typedefs (and watch out for possible
arch-specific overrides of generic type choices)...

> In a first analysis of this, I noticed that it is impossible to run
> qemu-sparc64
> under gdb (raised fatal signal).

You probably just need to let the signals go through to
the target... I noticed that it had a tendency to do lots
of (presumably safely handled) segfaulting while running;
didn't look at why this happens.

> I was also surprised to see that
> target_stat64 is unused.

sparc64 provides a stat64 syscall (probably for backward
compatibility), but any sensibly compiled libc should just
use stat, since with 64 bit longs the fields are all sensible
sizes anyway.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]