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 <[EMAIL PROTECTED]>