[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] qemu-i386 maple apt-get

From: Franz-Josef Haider
Subject: Re: [Qemu-discuss] qemu-i386 maple apt-get
Date: Thu, 14 Jan 2016 14:50:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 01/07/2016 08:18 PM, Peter Maydell wrote:
On 22 December 2015 at 21:37, Franz-Josef Haider
<address@hidden>  wrote:
This is a sarge installation. Executing apt-get update triggers the crash
for me.

OK, I've now been able to try that on my hardware.

(1) If I use your chroot, and the qemu binary you provide in the
tarball, then apt-get update does crash. More simply, so does:
   chroot . ./usr/bin/qemu-i386 /bin/cp

(This is helpful, because it means we can easily run it under gdb:
   gdb --args chroot . ./usr/bin/qemu-i386 /bin/cp

(2) If I build my own QEMU binary, it doesn't crash on either cp
or apt-get; that works fine. My guess is that something about
your build setup (maybe the libc you're linking against, or the
compiler) is different from mine in a way that means this only
causes an actual crash for your builds and not mine.

Unfortunately the binary you've supplied seems to have been stripped,
so it has absolutely no debug or symbol information that we could
use to figure out what's going on (beyond that the PC is in the
.text segment so it's a crash in the C code rather than in the
generated code, which we suspected anyway from the debug log).

Could you produce a QEMU binary that isn't stripped and which
provokes the problem and send it to me, along with the info about
which QEMU git commit you built it from, please? (QEMU's makefiles
only run strip on install so it should be sufficient to fish out
the unstripped binary from the build tree; or you can pass
configure --disable-strip. 'file qemu-i386' will tell you if
it's stripped or not.)

-- PMM

This would be a unstripped version of the qemu-i386 binary: https://www.dropbox.com/s/s9f8pcn5co34khn/qemu-i386?dl=0, although i think it is not worth trying to pursue this any further, because i have updated GCC in my build chroot (scratchbox) to version 4.7.2 and libc to 2.5.1 (which were available in some third party repositories for my device) which still seems ancient but far better than what i had previously. The crash is gone now.

But i had to apply the attached patch in order for it to compile.
Seems like -Wno-sign-compare has to be after -Wall and std::abs has no "long long int" version on this compiler.

Thanks for your time and effort!

Attachment: sign.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]