Re: Debug buildtype broken
On Wednesday, 19. September 2007, David Faure wrote: -fno-reorder-blocks makes step-by-step debugging very hard, despite what Dirk and Thiago might say. it depends on your gcc version of course. there are still many outstanding issues, but it is a longer term goal to make this work. I however would not like to see an option for -g3 - we're not using that much macros to justify the tremendous overhead. However the point of having -O2 in the default flags is that -O2 gives better warnings than -O0. Yes, this is the main point. It also gives you a variable and code layout that is similar to the release builds that are part of a distribution. I can't stress this point enough because I'm often debugging issues that go away with -O0 and are therefore claimed to be compiler bugs, even though the bug is in the actual source, just that optimisation uncovered it. It is not an often done debugging job to debug a heavily eventbased interactive application (like KDE applications generally are) in a debugger and stepping through it line by line. it is just too complex, especially if you have to step through hundreds of inline expansions of trivial accessors to get somewhere. therefore, the default debug build should be a reasonable optimized build with good backtraces. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Debug buildtype broken
On 22.09.07 00:33:25, Dirk Mueller wrote: It is not an often done debugging job to debug a heavily eventbased interactive application (like KDE applications generally are) in a debugger and stepping through it line by line. I disagree (but then I've done only one year of KDE development, so maybe I'm still too young in this business ;) it is just too complex, especially if you have to step through hundreds of inline expansions of trivial accessors to get somewhere. With a reasonable user interface for your debugger you don't step through hundreds of inline'd accessor methods. You step through maybe a hundred lines of code that may contain the problem. I try to use the debugger more often than the debug-by-printing system, because if the debugger works its often faster to reveal the real issue. At least thats my experience working on KDevelop3 and its QMake support (which of course has some non-gui part). therefore, the default debug build should be a reasonable optimized build with good backtraces. Ok, I understand and can live with that. However that means we don't get proper stepable apps on win32 as debugfull doesn't exist there. The question is: Should we have debug with -O0 on win32 or take this issue upstream to cmake and try to solve it there (possibly requiring cmake 2.4.7 or .8 for win32 debug builds)? Andreas -- A few hours grace before the madness begins again. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Debug buildtype broken
Hi list! Can anybody tell me why do we need a RelWithDebugInfo, and Debug and Debugfull? I can understand that we need 2 of them, one to be able to run the program with some debug information but being fast and the other to debug the program (which means being able to add breakpoints, and jump by steps and so). Maybe debugfull should be used for more unusual cases such as using gcov or with flags like -ggdb3 that are much more drastic, otherwise it is useless to have debug IMHO. Bye! Aleix PS: Now I see that I am basically saying the same as Andreas's :P, well here it is my opinion. On 9/19/07, Andreas Pakulat [EMAIL PROTECTED] wrote: Hi, in kdelibs the CXX and CFLAGS for Debug builds are set to include -g -O2 which breaks debug builds. This way debug builds are usable _only_ for getting backtraces, but not for actual debugging because this lets gcc optimize away some local variables and also makes stepping through code nearly impossible (each step may jump forth and back through the current function). The only workaround is using debugfull buildtype, which doesn't exist on win32, so I suspect its impossible to do debugging with MinGW. I suggest to change this to -g -O0 and leave -g -O2 to RelWithDebugInfo, which currently is nearly the same as Debug. Andreas -- Today is the first day of the rest of your life. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Debug buildtype broken
Andreas Pakulat wrote: Hi, in kdelibs the CXX and CFLAGS for Debug builds are set to include -g -O2 which breaks debug builds. This way debug builds are usable _only_ for getting backtraces, but not for actual debugging because this lets gcc optimize away some local variables and also makes stepping through code nearly impossible (each step may jump forth and back through the current function). The only workaround is using debugfull buildtype, which doesn't exist on win32, so I suspect its impossible to do debugging with MinGW. I suggest to change this to -g -O0 and leave -g -O2 to RelWithDebugInfo, which currently is nearly the same as Debug. Some flags suggestions: Release: -O2 RelWithDebugInfo: -g -O2 optimised-but-debuggable: -g -O2 -fno-inline -fno-schedule-insns -fno-reorder-blocks Debug: -g -O0 Debugfull: -g3 -O0 RelWithDebugInfo is not suitable for debugging. It's enough to get backtraces, though. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Debug buildtype broken
On 19.09.07 20:15:43, Thiago Macieira wrote: Andreas Pakulat wrote: Hi, in kdelibs the CXX and CFLAGS for Debug builds are set to include -g -O2 which breaks debug builds. This way debug builds are usable _only_ for getting backtraces, but not for actual debugging because this lets gcc optimize away some local variables and also makes stepping through code nearly impossible (each step may jump forth and back through the current function). The only workaround is using debugfull buildtype, which doesn't exist on win32, so I suspect its impossible to do debugging with MinGW. I suggest to change this to -g -O0 and leave -g -O2 to RelWithDebugInfo, which currently is nearly the same as Debug. Some flags suggestions: Release: -O2 RelWithDebugInfo: -g -O2 optimised-but-debuggable: -g -O2 -fno-inline -fno-schedule-insns -fno-reorder-blocks Thats whats used for Debug right now and it doesn't work at all. I guess gcc just ignores the -f's and optimizes according to -O2. Debug: -g -O0 Debugfull: -g3 -O0 I'll change FindKDE4Internal.cmake next Monday then with the attached patch. (Unless somebody has objections of course). Andreas -- Keep it short for pithy sake. Index: FindKDE4Internal.cmake === --- FindKDE4Internal.cmake (Revision 714235) +++ FindKDE4Internal.cmake (Arbeitskopie) @@ -775,12 +775,12 @@ # Select flags. set(CMAKE_CXX_FLAGS_RELWITHDEBINFO -O2 -g) set(CMAKE_CXX_FLAGS_RELEASE-O2) - set(CMAKE_CXX_FLAGS_DEBUG -g -O2 -fno-reorder-blocks -fno-schedule-insns -fno-inline) + set(CMAKE_CXX_FLAGS_DEBUG -g -O0) set(CMAKE_CXX_FLAGS_DEBUGFULL -g3 -fno-inline) set(CMAKE_CXX_FLAGS_PROFILE-g3 -fno-inline -ftest-coverage -fprofile-arcs) set(CMAKE_C_FLAGS_RELWITHDEBINFO -O2 -g) set(CMAKE_C_FLAGS_RELEASE -O2) - set(CMAKE_C_FLAGS_DEBUG-g -O2 -fno-reorder-blocks -fno-schedule-insns -fno-inline) + set(CMAKE_C_FLAGS_DEBUG-g -O0) set(CMAKE_C_FLAGS_DEBUGFULL-g3 -fno-inline) set(CMAKE_C_FLAGS_PROFILE -g3 -fno-inline -ftest-coverage -fprofile-arcs) ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Debug buildtype broken
On Wednesday 19 September 2007, Andreas Pakulat wrote: On 19.09.07 20:15:43, Thiago Macieira wrote: Some flags suggestions: Release: -O2 RelWithDebugInfo: -g -O2 optimised-but-debuggable: -g -O2 -fno-inline -fno-schedule-insns -fno-reorder-blocks Thats whats used for Debug right now and it doesn't work at all. I guess gcc just ignores the -f's and optimizes according to -O2. Debug: -g -O0 Debugfull: -g3 -O0 I'll change FindKDE4Internal.cmake next Monday then with the attached patch. (Unless somebody has objections of course). You're ignoring previous discussions on this... I do agree that -g -O2 -fno-inline -fno-schedule-insns -fno-reorder-blocks makes step-by-step debugging very hard, despite what Dirk and Thiago might say. However the point of having -O2 in the default flags is that -O2 gives better warnings than -O0. Without optimization, you get no warnings in many cases (e.g. unused local variable, etc.), and since there are more people compiling KDE than there are people doing step-by-step debugging, it's not completely wrong to have -O2 in the default flags... People who want to use gdb can use Debugfull -- just like we did in KDE3. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Debug buildtype broken
On 19.09.07 22:18:12, David Faure wrote: On Wednesday 19 September 2007, Andreas Pakulat wrote: On 19.09.07 20:15:43, Thiago Macieira wrote: Some flags suggestions: Release: -O2 RelWithDebugInfo: -g -O2 optimised-but-debuggable: -g -O2 -fno-inline -fno-schedule-insns -fno-reorder-blocks Thats whats used for Debug right now and it doesn't work at all. I guess gcc just ignores the -f's and optimizes according to -O2. Debug: -g -O0 Debugfull: -g3 -O0 I'll change FindKDE4Internal.cmake next Monday then with the attached patch. (Unless somebody has objections of course). You're ignoring previous discussions on this... Sorry, I didn't try to dig into the archive. I do agree that -g -O2 -fno-inline -fno-schedule-insns -fno-reorder-blocks makes step-by-step debugging very hard, despite what Dirk and Thiago might say. Uhm, it makes it impossible because you can't follow the code flow. It also makes it impossible to see certain variables. That mode is completely useless for _anything_ besides good backtraces. However the point of having -O2 in the default flags is that -O2 gives better warnings than -O0. Without optimization, you get no warnings in many cases (e.g. unused local variable, etc.), Strange, I build kdevplatform and kdevelop here with debugfull (-g3 -O0) and I get tons of warnings, including unused local variables. and since there are more people compiling KDE than there are people doing step-by-step debugging, it's not completely wrong to have -O2 in the default flags... People who want to use gdb can use Debugfull -- just like we did in KDE3. debugfull is not available on all platforms. Also I don't see the problem, first time builders should be using Release (when KDE4 is released) or RelWithDbgInfo (to get backtraces for initial debugging). A Debug build IMHO implicates that its usable for debugging code, which is clearly not the case for the current setup. Andreas -- Generosity and perfection are your everlasting goals. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
