Scrollbars and scrollwheel: -fomit-frame-pointer problems
Hi, Seems like I found out which flags causes trouble with the scrollbars and the mouse's scrollwheel: building wine without -fomit-frame-pointer flag makes it work right. This fixes my problem ( http://article.gmane.org/gmane.comp.emulators.wine.devel/23780 ) and seems to fix (at least for me) the problem reported by Nguyen Tuan Anh ( http://article.gmane.org/gmane.comp.emulators.wine.user/7169 ). I actually don't know how to filter with autoconf and stuff the specified flag, I only know with gentoo's portage, but I hope there's a way to make this flag doesn't go to the gcc parameters. Regards, -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/
Seems like I found out which flags causes trouble with the scrollbars and the mouse's scrollwheel: building wine without -fomit-frame-pointer flag makes it work right.
Using this switch is almost always a bad idea, as it makes getting backtraces impossible. OK, without debug symbols, they are of only limited usefulness but I've still been able to track down problems before using a stripped backtrace. -fomit-frame-pointer is one of those "optimizations" that does more harm than good in my opinion. If you are right and this is causing misbuilds, perhaps we should have a check in the configure script for over-agressive optimization. Alexandre?
Mike Hearn wrote:
Using this switch is almost always a bad idea, as it makes getting backtraces impossible. OK, without debug symbols, they are of only limited usefulness but I've still been able to track down problems before using a stripped backtrace. I build quite everything in Gentoo with -fomit-frame-pointer, but I haven had so many problems, sometimes a build process fails, and many ebuilds filter that flag (wine's doesn't anyway), but I never saw a problem like that of a build process correct and then an internal problem.
If you are right and this is causing misbuilds, perhaps we should have a check in the configure script for over-agressive optimization. Alexandre? I have resolved my problems removing that flag, however I can't be sure for Nguyen Tuan Anh with Mandrake 10 because I don't have one and I don't know if the Mandrake's flags are similar to the one Acke Carlsson sent me from Mandrake 9.2 (but I think so). In this case that binaries are built with -fomit-frame-pointer and the teory of Rein Klazes is right, the problems are in Mandrake Binaries and by-hand compiled versions with -fomit-frame-pointer flag (like mine).
Regards, -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/
-fomit-frame-pointer is one of those "optimizations" that does more harm than good in my opinion.
Well, I always found the resulting assembly of code compiled with '-fomit-frame-pointer' much easier to read than without :-)
If you are right and this is causing misbuilds, perhaps we should have a check in the configure script for over-agressive optimization. Alexandre?
Why not first try to search for the bug and report it to the GCC people ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer wrote:
Why not first try to search for the bug and report it to the GCC people ? IMHO Wine has so much things to take care of that are more important than a GCC bug that the better way to handle this for now is to filter off that flag.
There're also other softwares which filter some flags, or that can't be build correctly with certainly flags. If you take the gentoo's ebuilds there are a lot of filter-flag commands to remove some flags (-fforce-addr for example make xine's build process merely fail). -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/
Well, I always found the resulting assembly of code compiled with '-fomit-frame-pointer' much easier to read than without :-)
Heh, I always find it hard :)
Why not first try to search for the bug and report it to the GCC people ?
If your disassembly-fu is up to it, be my guest ... that doesn't solve the problem of mysterious crashes for people using/compiling Wine today though. So I'd still vote for a configure check.
Heh, I always find it hard :)
Well, my example was on code generated for ARM which is unreadable when the complier saves the frame pointer :-)
If your disassembly-fu is up to it, be my guest ... that doesn't solve the problem of mysterious crashes for people using/compiling Wine today though. So I'd still vote for a configure check.
I agree with the configure check (we already have one for the bug Eric found about a strength-reduce bug). On the other hand, the whole point of Open Source is helping each other and if we just say 'oh well, it's easier for us to just remove the optimisation flag' and forget the issue, it's an opportunity lost to improve GCC. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer wrote:
Open Source is helping each other and if we just say 'oh well, it's easier for us to just remove the optimisation flag' and forget the issue, it's an opportunity lost to improve GCC. We can report this to gcc developers, but, at least on my side, I don't know enough how GCC works low level to try to fix it up.
Actually we don't know either which code creates the problem (also if we know that the problem is, with an high probably rate, on scrollbars), so I think we can add the configure check and then fill a bug which reports this if someone has the skills and the time to fix it. -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/
Mike Hearn <m.hearn(a)signal.qinetiq.com> writes:
If your disassembly-fu is up to it, be my guest ... that doesn't solve the problem of mysterious crashes for people using/compiling Wine today though. So I'd still vote for a configure check.
You need to know what the bug is in order to write a proper configure check, so the first thing to do is to figure out why that flag causes trouble. -- Alexandre Julliard julliard(a)winehq.org
On Friday 03 September 2004 17:40, Alexandre Julliard wrote:
Mike Hearn <m.hearn(a)signal.qinetiq.com> writes:
If your disassembly-fu is up to it, be my guest ... that doesn't solve the problem of mysterious crashes for people using/compiling Wine today though. So I'd still vote for a configure check.
You need to know what the bug is in order to write a proper configure check, so the first thing to do is to figure out why that flag causes trouble.
Know and know, I know at least it was this patch http://www.winehq.org/hypermail/wine-cvs/2004/06/0120.html that introduce this behaviour. mvh Acke
On Sat, 4 Sep 2004 01:32:16 +0200, you wrote:
You need to know what the bug is in order to write a proper configure check, so the first thing to do is to figure out why that flag causes trouble.
Know and know, I know at least it was this patch http://www.winehq.org/hypermail/wine-cvs/2004/06/0120.html that introduce this behaviour.
Yes, I have send a fix for this to wine-patches. Rein. -- Rein Klazes rklazes(a)xs4all.nl
participants (6)
-
Acke Carlsson -
Alexandre Julliard -
Diego 'Flameeyes' Pettenò -
Lionel Ulmer -
Mike Hearn -
Rein Klazes