Re: [Qemu-devel] Re: qemu-ppc can't run static uClibc binaries.

[Rob Landley <rob@landley.net>]

On Thursday 18 February 2010 05:38:01 Artyom Tarasenko wrote:
> 2010/2/17 Blue Swirl <blauwirbel@gmail.com>:
> > On Wed, Feb 17, 2010 at 8:55 PM, Rob Landley <rob@landley.net> 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?
> >>>
> >>>  From 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
> >> never had it die with strange errors that look like mismatched system
> >> calls and such. (Under ubuntu 8.04, using qemu-git from a week or so
> >> back, but this behavior'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.  (It's a read-only root filesystem
> >> that hasn't got a mount point for /proc.  Obviously 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_
> >> on sparc, so the problems I'm seeing are more likely to be uClibc or
> >> toolchain issues.
> >>
> >> Alas the image has no hint how to reproduce it.  Doesn't say what
> >> toolchain it was built with, what kernel .config was used, and so on.
> >>  (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).  So
> >> it was built with a random cvs snapshot of egcs from 2001, configured
> >> who knows how, and it's running a 2.6.11 kernel from 5 years ago (again
> >> with who knows what .config).  So my problem could be that I'm using a
> >> kernel 22 versions newer, or I'm using gcc 4.2 toolchain, or that either
> >> is configured differently.
> >
> > 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-aware. The comments in the kenel source like "this could be a qemu
> bug" from the Rob's mail "proper fix"
> (http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-January/079436.html)
> scare me.

Unless sparc is also using the zilog serial chip (the driver for which has 
"pmac" in its name), that was a power macintosh issue. :)

And yeah, qemu's behavior was apparently a bit iffy with regard to what the 
hardware was actually doing, but not beyond what the datasheets said could 
happen, and the kernel guys put in a workaround...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds