Re: [Qemu-devel] RFC: fix for random Qemu crashes

[Jocelyn Mayer]

On Fri, 2007-11-16 at 17:42 +0200, Heikki Lindholm wrote:
> Jocelyn Mayer kirjoitti:
> > On Fri, 2007-11-16 at 17:06 +0200, Heikki Lindholm wrote:
> >> J. Mayer kirjoitti:
> >>> Some may have experienced of having some Qemu builds crashing,
> >>> apparently at random places, but in a reproducable way.
> >>> I found one reason for this crashes: it appears that with the growth of
> >>> the op.c file, there may be cases where we could reach the inlining
> >>> limits of gcc. In such a case, gcc would not inline some declared
> >>> "inline" function but would emit a call and provide a separate function.
> >>> Unfortunately, this is not acceptable in op.o context as it will
> >>> slowdown the emulation and because the call is likely to break the
> >>> specific compilation rules (ie reserved registers) used while compiling
> >>> op.o
> >> Does -winline give a warning when this happens?
> > 
> > I did not check this, but getting a warning won't help us a lot. The
> > generated Qemu executable would still crash.
> 
> But a warning makes the problem more noticable.

yes, sure.

>  I tried -Winline and it 
> does give warnings, but I'm not sure whether I'm hitting the same 
> behaviour you see. I silenced the lot with 
> --param-max-inline-insns-single=4000

This is not sufficient. You will still have problems if triggering the
growth limit of a single function or the whole compilation unit.
Furthermore, 4000 is not a lot, I think it should be set to a very high
value we could never reach in real cases.


I did a build with current CVS and the -Winline switch set, using
gcc-3.4.6 on a x86_64 host. This showed me more problems than I
expected:

while compiling slirp code, I got a lot of warnings from slirp headers:
warning: inlining failed in call to 'slirp_remque': function body not
available
Those seem to be real bugs to be fixed.

from linux-user/syscall.c, I got a lot of warnings "--param
large-function-growth limit reached" in tswap32/tswap64 functions. This
does not seem to be critical, as syscall is actually a slow operation.

from target-i386/helper.c, I got a gew warnings "--param
max-inline-insns-single limit reached"

from target-arm/translate.c, got a few "--param max-inline-insns-single
limit reached"

from target-sparc/translate.c, got a few "--param
max-inline-insns-single limit reached after inlining into the callee"

from target-mips/translate.c: got a lot of "--param inline-unit-growth
limit reached" from gen-op.h, which can be quite a problem
from target-mips/op_helper.c: a lot of " --param inline-unit-growth
 limit reached", mostly for load/store functions, which may be
problematic.

from target-alpha/translate.c: got a lot of "--param inline-unit-growth
limit reached"

More warnings are issued for full system emulation:
from target-i386/translate.c: a lot of "--param large-function-growth
limit reached" from softmmu_header.h, which means code fetch is done via
function, which is not great.

from hw/pxa2xx.c: "--param large-function-growth limit reached". Should
not be problematic.

from target-ppc/helper.c: lots of "--param inline-unit-growth limit
reached" for load/store functions, which may be problematic

I noticed no warnings from target-ppc/op.c. But I've seen the bug
triggered with the build I done before commiting wy latest patches (with
those patches applied to a clean repository...) for the PowerPC 64
target, resulting in an emulator that would crash while entering user
mode (with the CDROM images I tested).
I'm not sure if there could be some cases gcc won't warn even when not
inlining an declared inline function, or if the bug what not triggered
this time, for an unknown reason as I just did a build from a checkout
with just the -Winline flag added (then the build should be quite
equivalent to the one I did this morning before commiting).

-- 
Jocelyn Mayer <address@hidden>