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

[Artyom Tarasenko]

2010/2/18 Rob Landley <address@hidden>:
> On Thursday 18 February 2010 05:38:01 Artyom Tarasenko wrote:
>> 2010/2/17 Blue Swirl <address@hidden>:
>> > On Wed, Feb 17, 2010 at 8:55 PM, Rob Landley <address@hidden> 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. :)

Sparc does use the Zilog serial chip, according to  hw/escc.c it is a bit
different from the pmac chip though. There seem to be issues with its emulation,
for instance, Solaris 1.1.2 hangs after putting 2 bytes (which I
believe is the hw buffer size):

http://tyom.blogspot.com/2009/09/wh-sunos-414-under-qemu-system-sparc.html

> 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...

Good for the kernel, bad for qemu: lots of chips have bad
documentation. Nevertheless they have some certain behavior, which
qemu should emulate. Now linux kernel has this workaround, which makes
it more robust, but less useful for regression testing.

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/