From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHhAB-0000qx-Up for qemu-devel@nongnu.org; Thu, 05 Sep 2013 17:32:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHhA7-000501-Hh for qemu-devel@nongnu.org; Thu, 05 Sep 2013 17:32:27 -0400 Received: from mail-lb0-f176.google.com ([209.85.217.176]:49616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHhA7-0004zm-Am for qemu-devel@nongnu.org; Thu, 05 Sep 2013 17:32:23 -0400 Received: by mail-lb0-f176.google.com with SMTP id y6so2171840lbh.21 for ; Thu, 05 Sep 2013 14:32:22 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <5228EB17.4050209@weilnetz.de> References: <5228EB17.4050209@weilnetz.de> From: Peter Maydell Date: Thu, 5 Sep 2013 22:32:02 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [Bug] qemu-sparc64 broken List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel On 5 September 2013 21:35, Stefan Weil 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