From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1It3Kt-0007hp-SP
	for qemu-devel@nongnu.org; Fri, 16 Nov 2007 10:42:27 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1It3Kq-0007gN-Os
	for qemu-devel@nongnu.org; Fri, 16 Nov 2007 10:42:27 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1It3Kq-0007g9-G0
	for qemu-devel@nongnu.org; Fri, 16 Nov 2007 10:42:24 -0500
Received: from emh05.mail.saunalahti.fi ([62.142.5.111])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <holindho@cs.helsinki.fi>) id 1It3Ko-0001b8-TE
	for qemu-devel@nongnu.org; Fri, 16 Nov 2007 10:42:23 -0500
Message-ID: <473DBA59.9030602@cs.helsinki.fi>
Date: Fri, 16 Nov 2007 17:42:17 +0200
From: Heikki Lindholm <holindho@cs.helsinki.fi>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] RFC: fix for random Qemu crashes
References: <1195168693.2415.19.camel@rapid> <473DB212.9010300@cs.helsinki.fi>
	<1195227348.28318.4.camel@jma4.dev.netgem.com>
In-Reply-To: <1195227348.28318.4.camel@jma4.dev.netgem.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: l_indien@magic.fr, qemu-devel@nongnu.org

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

-- Heikki Lindholm