From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BTjtv-0003O0-AU for qemu-devel@nongnu.org; Fri, 28 May 2004 12:08:07 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BTjtJ-0003EV-Ox for qemu-devel@nongnu.org; Fri, 28 May 2004 12:08:04 -0400 Received: from [194.226.236.116] (helo=ums.usu.ru) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BThk6-0007sW-Fv for qemu-devel@nongnu.org; Fri, 28 May 2004 09:49:51 -0400 Message-ID: <40B743C0.8020003@ums.usu.ru> Date: Fri, 28 May 2004 19:50:56 +0600 From: "Alexander E. Patrakov" MIME-Version: 1.0 Subject: [SOLVED] Re: [Qemu-devel] Overoptimization References: <40B693A7.9050006@ums.usu.ru> <20040528101351.GA18592@MAIL.13thfloor.at> <40B71B59.7080406@ums.usu.ru> <20040528110838.GA19126@MAIL.13thfloor.at> In-Reply-To: <20040528110838.GA19126@MAIL.13thfloor.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Herbert Poetzl Cc: qemu-devel@nongnu.org Herbert Poetzl wrote: > On Fri, May 28, 2004 at 04:58:33PM +0600, Alexander E. Patrakov wrote: > >>Herbert Poetzl wrote: >> >>>On Fri, May 28, 2004 at 07:19:35AM +0600, Alexander E. Patrakov wrote: >>> >>> >>>>The CFLAGS in Makefile.target are bad for gcc 3.3.2. This is not a my >>>>problem with my gcc, because it passes the "make check" testsuite except >>>>some known errors in libstdc++, which cannot affect qemu. >>>> >>>>The victim is the tcp_input function in slirp. When compiling with the >>>>decault CFLAGS, for some reason all packets are dropped as having a >>>>wrong TCP checksum. I tried debugging this by placing some debug printfs >>>>in tcp_input.c file, but the problem disappeared after I inserted them. >>>>I concluded that it is very strange and compiled this tcp_input.c file >>>>without my debug statements, but with -O1 instead of -O2. The problem >>>>went away. >>> >>> >>>gcc isn't supposed to change the semantics of >>>a program based on the optimization level. >>> >>>nevertheless several cases are known where this >>>happened, and not seldom the bug was in gcc >>> >>>testing the same opts with 3.3.3 or 3.4 will >>>show if gcc is to blame or not. >> >>Done (with gcc 3.4.0). I used a truly minimal configuration of qemu in >>both cases to make sure that this is not an SDL/X/whatever else problem: >> >>./configure --prefix=/usr --target-list=i386-softmmu --enable-slirp >>--disable-sdl >> >>GCC 3.4.0, however, required one more file to be compiled with -O1 >>(because of some register allocation error), and there were some "struct >>timezone" errors that were trivial to fix by including where >>appropriate. >> >>The result is the same. If I compile tcp_input.c with -O2, all tcp >>packets are rejected in user-net mode because of wrong tcp checksum. If >>tcp_input.c is compiled with -O1, qemu works. > > > okay, sounds like some 'broken' struct, which might > get misaligned or maybe a problem with the binutils ... HJL binutils 2.15.90.0.3, there are 5 known failures during "make check", all are TLS-related and probably don't affect qemu. > I'd suggest trying -Os and -O9 just to give some hints > to the developers, also the detailed error messages > of the specific code with -Wall might shed some light > on that ... In fact I just had to read the gcc info page and remove optimizations one by one. Result, with gcc 3.3.2: -Wall -O2 -g -fomit-frame-pointer (defaults) = unsafe, -Wall -O2 -g -fomit-frame-pointer -fno-strict-aliasing = safe. So it looks like slirp code breaks strict aliasing rules assumed by -O2. Since the problem has been identified precisely, it has to be fixed in qemu CVS. -- Alexander E. Patrakov