From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ni4iC-00056L-4i for qemu-devel@nongnu.org; Thu, 18 Feb 2010 06:38:28 -0500 Received: from [199.232.76.173] (port=54368 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ni4iB-00056A-Hn for qemu-devel@nongnu.org; Thu, 18 Feb 2010 06:38:27 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Ni4i9-0000AE-5O for qemu-devel@nongnu.org; Thu, 18 Feb 2010 06:38:27 -0500 Received: from mx20.gnu.org ([199.232.41.8]:15659) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ni4i8-0000A9-T8 for qemu-devel@nongnu.org; Thu, 18 Feb 2010 06:38:25 -0500 Received: from mail-pz0-f176.google.com ([209.85.222.176]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ni4i7-0003B1-Id for qemu-devel@nongnu.org; Thu, 18 Feb 2010 06:38:23 -0500 Received: by pzk6 with SMTP id 6so2467797pzk.18 for ; Thu, 18 Feb 2010 03:38:21 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <201002110520.07620.rob@landley.net> <4B7C0F2C.1080409@redhat.com> <201002171255.34570.rob@landley.net> From: Artyom Tarasenko Date: Thu, 18 Feb 2010 12:38:01 +0100 Message-ID: Subject: Re: [Qemu-devel] Re: qemu-ppc can't run static uClibc binaries. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Paolo Bonzini , qemu-devel@nongnu.org 2010/2/17 Blue Swirl : > On Wed, Feb 17, 2010 at 8:55 PM, Rob Landley wrote: >> On Wednesday 17 February 2010 09:45:48 Paolo Bonzini wrote: >>> On 02/17/2010 10:24 AM, Artyom Tarasenko wrote: >>> >> I've also got a bunch of "sort of working, but not well enough >>> >> to run builds natively under" targets on top of that (arm big >>> >> endian, sh4, sparc...) >>> > >>> > What's not well enough on sparc? >>> >>> =A0From http://permalink.gmane.org/gmane.comp.emulators.qemu/63610: >>> >>> On Linux, sparc-softmmu can boot Linux (sparc-test) image, but QEMU >>> crashes just before command line. On OpenBSD, the same test reaches >>> command prompt. > > That's status for sparc host. On x86 host, everything should work fine > except for a few known issues. > >> Actually the sparc-test image from http://wiki.qemu.org/download/sparc- >> test-0.2.tar.gz boots and gets me a command line just fine, and I've nev= er had >> it die with strange errors that look like mismatched system calls and su= ch. >> (Under ubuntu 8.04, using qemu-git from a week or so back, but this beha= vior's >> been consistent since I first tried it.0 >> >> That image is A) built with an unknown compiler, B) running glibc (not >> uClibc), c) a crippled toy image. =A0(It's a read-only root filesystem t= hat >> hasn't got a mount point for /proc. =A0Obviously never mean to actually = be used >> for anything but very simple smoke testing.) >> >> But it does imply that qemu is capable of decently running _something_ o= n >> sparc, so the problems I'm seeing are more likely to be uClibc or toolch= ain >> issues. >> >> Alas the image has no hint how to reproduce it. =A0Doesn't say what tool= chain it >> was built with, what kernel .config was used, and so on. =A0(The arm one= at least >> had /proc/config.gz...) >> >> Well, actually if you "mount -t proc proc lost+found" and then cat >> lost+found/version it says gcc version 2.95.4 20010319 (prerelease). =A0= So it >> was built with a random cvs snapshot of egcs from 2001, configured who k= nows >> how, and it's running a 2.6.11 kernel from 5 years ago (again with who k= nows >> what .config). =A0So my problem could be that I'm using a kernel 22 vers= ions >> newer, or I'm using gcc 4.2 toolchain, or that either is configured diff= erently. > > The compiler was probably Debian gcc 2.95 package as distributed that > time, not some random cvs snapshot of egcs. I can't find the original > kernel config because I have edited it since, but the attached version > should not be too far from it. The kernel itself is straight 2.6.11 > plus this patch to fix TCX display. I think the ramdisk contents are > from the user emulator test set, I didn't build those. > > Perhaps we should build a new set of test suites for all architectures > from a single known stack of tools and sources. And still based on preferably old enogh kernel version which wasn't qemu-aw= are. The comments in the kenel source like "this could be a qemu bug" from the R= ob's mail "proper fix" (http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-January/079436.html) scare me. --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/