On 5 September 2013 21:35, Stefan Weil <s...@weilnetz.de> 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
