From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NhmtI-0006fM-SN for qemu-devel@nongnu.org; Wed, 17 Feb 2010 11:36:45 -0500 Received: from [199.232.76.173] (port=36977 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NhmtG-0006e9-KD for qemu-devel@nongnu.org; Wed, 17 Feb 2010 11:36:42 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NhmtE-0003US-Es for qemu-devel@nongnu.org; Wed, 17 Feb 2010 11:36:42 -0500 Received: from [71.162.243.5] (port=54534 helo=grelber.thyrsus.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NhmtE-0003UO-42 for qemu-devel@nongnu.org; Wed, 17 Feb 2010 11:36:40 -0500 From: Rob Landley Subject: Re: [Qemu-devel] Re: qemu-ppc can't run static uClibc binaries. Date: Wed, 17 Feb 2010 10:36:32 -0600 References: <201002110520.07620.rob@landley.net> <201002161214.31083.rob@landley.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201002171036.32899.rob@landley.net> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel@nongnu.org On Wednesday 17 February 2010 03:24:58 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? More than one thing, unfortunately. (Symptoms I can give you, causes I'm iffy on.) 1) the uClibc 0.9.32.2 dynamic linker isn't working on 32-bit sparc. (I believe it's a uClibc issue, not specifically qemu problem. But then since I don't own real sparc hardware, I dunno.) 2) Not all of the system calls work (again, probably a uClibc issue). 3) I'm not sure my toolchain configuration is quite matching the instruction set qemu-system-sparc is emulating by default, I get occasional illegal instruction errors (but not reliably). (Are #1 and #2 related to this? Dunno.) If I statically link everything I can at least get to a command prompt, but only with init=/bin/sh. (If I try to run it through the boot script, it dies with various errors from "cannot allocate memory" to "Illegal insruction".) If you're curious you can play around with the prebuilt binary at http://impactlinux.com/fwl/downloads/binaries/system-image-sparc.tar.bz2 but you'll have to boot it like this to bypass the boot script: KERNEL_EXTRA="init=/bin/ash" ./run-emulator.sh Then to see it misbehave: # mount -t tmpfs /tmp /tmp # cd /tmp /tmp # ls ls: can't open '.': Cannot allocate memory /tmp # mount -t proc /proc /proc /tmp # ls -l /proc Illegal instruction The toolchain is configured with "sparc-unknown-linux" which you'd think would be generic sparc, but apparently not... If you prefer to build it from source, you can download http://impactlinux.com/fwl/downloads/firmware-0.9.10.tar.bz2 and run "./build.sh sparc", then look in the "build" directory when it's done. I'd happily explain how the build scripts work and what config options they're passing to the the toolchain and kernel and such, but this isn't the list for that. (http://impactlinux.com/fwl has a link to the FWL mailing list if you're interested.) I'd be thrilled to get some help on it actually, not a sparc expert... Thanks, Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds