From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ItLMu-0005ud-Jm for qemu-devel@nongnu.org; Sat, 17 Nov 2007 05:57:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ItLMu-0005uN-6g for qemu-devel@nongnu.org; Sat, 17 Nov 2007 05:57:44 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ItLMu-0005uK-1l for qemu-devel@nongnu.org; Sat, 17 Nov 2007 05:57:44 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ItLMt-00046G-PL for qemu-devel@nongnu.org; Sat, 17 Nov 2007 05:57:44 -0500 Received: by ug-out-1314.google.com with SMTP id m2so709319uge for ; Sat, 17 Nov 2007 02:57:42 -0800 (PST) Message-ID: Date: Sat, 17 Nov 2007 11:57:42 +0100 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] RFC: fix for random Qemu crashes In-Reply-To: <1195257843.5335.15.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1195168693.2415.19.camel@rapid> <200711161552.55645.paul@codesourcery.com> <1195229132.28318.10.camel@jma4.dev.netgem.com> <1195257843.5335.15.camel@rapid> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "J. Mayer" Cc: qemu-devel@nongnu.org On 17/11/2007, J. Mayer wrote: > > On Fri, 2007-11-16 at 21:32 +0100, andrzej zaborowski wrote: > > On 16/11/2007, Jocelyn Mayer wrote: > > > > > > On Fri, 2007-11-16 at 15:52 +0000, Paul Brook wrote: > > > > > Then, I choosed to replace 'inline' by 'always_inline', which is more > > > > > invasive but have less risks of side effects. The diff is attached in > > > > > always_inline.diff. > > > > > The last thing that helps solve the problem is to change the inlining > > > > > limits of gcc, at least to compile the op.o file. > > > > > > > > Presumably we only need one of the last two patches? It seems rather pointless > > > > to have always_inline *and* change the inlining heuristics. > > > > > > >From the tests I made, it seems that adding always_inline helps but > > > unfortunatelly does not solve all cases. Should check in the gcc source > > > code why it is so... > > > > > > > I'm ok with using always_inline for op.o (and things it uses directly) as this > > > > is required for correctness. I'm not convinced that that using always_inline > > > > everywhere is such a good idea. > > > > > > That's exactly what I did: I changed 'inline' to 'always_inline' in > > > headers that are included by op.c, I did not made any change in other > > > headers. > > > > I think a line like > > > > #define inline __attribute__ (( always_inline )) inline > > > > in dyngen-exec.h should be > > As I already pointed it in the first message of the thread, this kind of > define would expand recursivelly, which is particullary ugly, and which > can in some cases lead to compiler warnings or errors. I already had > this kind of problems using the linux kernel headers which preciselly > uses this definitition. My point here is that you can use dyngen-exec.h for the macro so that the functions are only always_inline'd when used in op.c, not in other files, I think that's what pbrook mean too. For example cpsr_write from target-arm/exec.h was used in op.c as well as in vl.c. There's no problem if it isn't inlined in vl.c, the fix should only affect op.c which is a special case, for other files let gcc decide in the way it was designed by gcc authors. > But, once again, adding always_inline to functions does not completelly > solve the problem (please read the thread !) or at least does not solves > it with all gcc versions. Yes, I'm not saying anything about the other part. Regards