[Qemu-devel] Overoptimization

[Qemu-devel] Overoptimization

[Alexander E. Patrakov]

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.

Will this workaround (use of -O1 instead of -O2 for tcp_input.c) enter 
the qemu CVS?

-- 
Alexander E. Patrakov

Re: [Qemu-devel] Overoptimization

[Herbert Poetzl]

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.

best,
Herbert

> Will this workaround (use of -O1 instead of -O2 for tcp_input.c) enter 
> the qemu CVS?
> 
> -- 
> Alexander E. Patrakov
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Overoptimization

[Alexander E. Patrakov]

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

-- 
Alexander E. Patrakov

Re: [Qemu-devel] Overoptimization

[Herbert Poetzl]

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

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

HTH,
Herbert

> -- 
> Alexander E. Patrakov

[SOLVED] Re: [Qemu-devel] Overoptimization

[Alexander E. Patrakov]

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

Re: [SOLVED] Re: [Qemu-devel] Overoptimization

[Lionel Ulmer]

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

I think this aliasing stuff will really provoke a LOT of bugs out there for
years to come...

For example, Wine switched to '-fno-strict-aliasing' a long time ago :-)

        Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

[Qemu-devel] VNC patch, the 3rd version

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1577 bytes --]

Hi,

in the attached patch you can find the support for VNC, which includes
portable keyboard support for SDL on non PC architectures.

Changes as compared to the 2nd version of the patch:
- cleanups (wine's keyboard support was dropped)
- keymaps from rdesktop are included
- SDL portable keyboard support added (you don't need LibVNCServer for
	that)
- incorporated Jim's synaptic patch
- applies cleanly against CVS as of now (use patch -p1, else the keymaps
	mess up your directory)

There is a problem with the synaptic patch: If I read it correctly, the
absolute flag cannot be set to 1. There is simply no line which can do
that.

Jim, if you read this, can you help a mediocre programmer and enlighten me
how to use your work?

Also, I was only able to test the SDL portable keyboard support using
DISPLAY=my_IRIX_machine. I had two problems with this IRIX machine: I
could not compile qemu on it, although I read something about MIPS
support, but then, I did not try very hard. The other problem I had: when
using "-vnc-and-sdl", SDL displayed everything more or less correctly, but
when I did not use vnc at all, SDL displayed only a black rectangle...
Strange. No such problem on my i386 Linux.

Another idea which hit me: I am not convinced that without guest drivers,
the synaptic patch helps VNC's mouse. So why not use the
graphical feedback when using the mouse to determine where the guest
cursor is now (and how far it lags behind/runs in front)? I know, it is
less than clean, but it would be fun! I think I will try it if nobody
yells at me.

Ciao,
Dscho



[-- Attachment #2: Type: APPLICATION/x-gunzip, Size: 22702 bytes --]

Re: [Qemu-devel] VNC patch, the 3rd version

[Jim C. Brown]

On Sat, May 29, 2004 at 08:18:10PM +0200, Johannes Schindelin wrote:
> Hi,
> 
<s>
> There is a problem with the synaptic patch: If I read it correctly, the
> absolute flag cannot be set to 1. There is simply no line which can do
> that.
> 

Correct. To do that on a real touchpad you have to set bit 7 of the mode bit
to 1. My patch doesn't support setting the mode bit.

> Jim, if you read this, can you help a mediocre programmer and enlighten me
> how to use your work?
> 

For now what you need to do is:

The simple yet ugly hack would be to, on line 732 of pckbd.c, check if bit
7 of val is set. If so, set absolute mode on.

if (val & 0x80) s->touchpad.absolute = 1; /* TODO: real support for changing the mode byte */

I'm trying to figure out how to implement this elegantly and support all
possible modes. As you can tell by my silence, I haven't figured this out yet.

> Another idea which hit me: I am not convinced that without guest drivers,
> the synaptic patch helps VNC's mouse.

It doesn't. Without guest drivers, the real touchpad emulates a normal mouse.
Unless absolute mode is turned on, the patch doesn't add much.

With absolute mode, it still doesn't add much due to missing functionality
such as guestures. How would I emulate guestures with a 2-button mouse
is the question here. (Emulating a third button or scrolling with a real mouse
that has a real scrollwheel is not that hard, but with a mere 2 button mouse
the problem becomes much harder.)

> So why not use the
> graphical feedback when using the mouse to determine where the guest
> cursor is now (and how far it lags behind/runs in front)? I know, it is
> less than clean, but it would be fun! I think I will try it if nobody
> yells at me.

Good luck. This will not be easy at all (for example, what if the guest OS is
showing a screenshot, which happens to include the image of the mouse pointer
-- and remember that each GUI has a different looking mouse pointer, and most
have several, which can be swapped in at random from the viewpoint of qemu) but 
if you can pull it off it could be a useful feature.

> 
> Ciao,
> Dscho
> 
> 


> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.