From: Eran I. <era...@gm...> - 2012-07-20 13:11:14
|
Hello, I am not sure whether this issue is related to MinGW or to GDB. Since I don't have this issue on Linux / Mac and it only happens on Windows 7 + MinGW, I decided to post it here - maybe someone else on this list face this issue in the past and can shed some light / provide some good tips on the matter. Now to the actual problem: When I debug my application which consists of many shared libraries ("dll"s, around 35 - 40) and I have a breakpoint set in one of the shared libraries the startup time of gdb is *very* slow ( I am talking here about 10 mins ). If I remove all the breakpoints and start the debugger, the debug session starts in a reasonable manner (still very slow compare to Linux) ~45 seconds. I can then place the breakpoints back and continue debugging. However, the above workaround does not work if I need to debug one of the shared libraries initialization code Some info about my environment: MinGW 4.6.1 (TDM) 32 bit - I tried the official one 4.7 from MinGW with no luck - the problem persists GDB 7.05 (note that I tried all versions of gdbs available on MinGW SF download page, from 6.8.5 -> 7.4 with no luck) Windows 7 64bit For comparison: GDB 7.4 on my Ubuntu 12.04 starts the debugging session under 5 seconds for the same application Any advise? -- Eran Ifrah Author of the cross platform, open source C++ IDE: http://www.codelite.org |
From: Earnie B. <ea...@us...> - 2012-07-20 15:30:49
|
On Fri, Jul 20, 2012 at 9:10 AM, Eran Ifrah wrote: > Hello, > > I am not sure whether this issue is related to MinGW or to GDB. > Since I don't have this issue on Linux / Mac and it only happens on Windows > 7 + MinGW, I decided to post it here - maybe someone else on this list face > this issue > in the past and can shed some light / provide some good tips on the matter. > > Now to the actual problem: > When I debug my application which consists of many shared libraries ("dll"s, > around 35 - 40) and I have a breakpoint set in one of the shared libraries > the startup time of gdb is *very* slow ( I am talking here about 10 mins ). > > If I remove all the breakpoints and start the debugger, the debug session > starts in a reasonable manner (still very slow compare to Linux) ~45 > seconds. > I can then place the breakpoints back and continue debugging. > > However, the above workaround does not work if I need to debug one of the > shared libraries initialization code > > Some info about my environment: > > MinGW 4.6.1 (TDM) 32 bit - I tried the official one 4.7 from MinGW with no > luck - the problem persists > GDB 7.05 (note that I tried all versions of gdbs available on MinGW SF > download page, from 6.8.5 -> 7.4 with no luck) > Windows 7 64bit > > For comparison: GDB 7.4 on my Ubuntu 12.04 starts the debugging session > under 5 seconds for the same application > > Any advise? I'll utter guesses since at this point I have no real idea. I'm going to guess you might have better experience if your GDB process is a 64bit process assuming your Windows 7 is a 64 bit CPU. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eran I. <era...@gm...> - 2012-07-20 15:49:45
|
On Fri, Jul 20, 2012 at 6:30 PM, Earnie Boyd <ea...@us...>wrote: > On Fri, Jul 20, 2012 at 9:10 AM, Eran Ifrah wrote: > > Hello, > > > > I am not sure whether this issue is related to MinGW or to GDB. > > Since I don't have this issue on Linux / Mac and it only happens on > Windows > > 7 + MinGW, I decided to post it here - maybe someone else on this list > face > > this issue > > in the past and can shed some light / provide some good tips on the > matter. > > > > Now to the actual problem: > > When I debug my application which consists of many shared libraries > ("dll"s, > > around 35 - 40) and I have a breakpoint set in one of the shared > libraries > > the startup time of gdb is *very* slow ( I am talking here about 10 mins > ). > > > > If I remove all the breakpoints and start the debugger, the debug session > > starts in a reasonable manner (still very slow compare to Linux) ~45 > > seconds. > > I can then place the breakpoints back and continue debugging. > > > > However, the above workaround does not work if I need to debug one of the > > shared libraries initialization code > > > > Some info about my environment: > > > > MinGW 4.6.1 (TDM) 32 bit - I tried the official one 4.7 from MinGW with > no > > luck - the problem persists > > GDB 7.05 (note that I tried all versions of gdbs available on MinGW SF > > download page, from 6.8.5 -> 7.4 with no luck) > > Windows 7 64bit > > > > For comparison: GDB 7.4 on my Ubuntu 12.04 starts the debugging session > > under 5 seconds for the same application > > > > Any advise? > > I'll utter guesses since at this point I have no real idea. I'm going > to guess you might have better experience if your GDB process is a > 64bit process assuming your Windows 7 is a 64 bit CPU. > > Thank you, I will try and get my hands on a 64bit gdb executable and will try it again -- > Earnie > -- https://sites.google.com/site/earnieboyd > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > -- Eran Ifrah Author of the cross platform, open source C++ IDE: http://www.codelite.org |
From: asmwarrior <asm...@gm...> - 2012-07-21 01:43:41
|
On 2012-7-20 21:10, Eran Ifrah wrote: > Hello, > > I am not sure whether this issue is related to MinGW or to GDB. > Since I don't have this issue on Linux / Mac and it only happens on Windows 7 + MinGW, I decided to post it here - maybe someone else on this list face this issue > in the past and can shed some light / provide some good tips on the matter. > > Now to the actual problem: > When I debug my application which consists of many shared libraries ("dll"s, around 35 - 40) and I have a breakpoint set in one of the shared libraries > the startup time of gdb is *very* slow ( I am talking here about 10 mins ). > > If I remove all the breakpoints and start the debugger, the debug session starts in a reasonable manner (still very slow compare to Linux) ~45 seconds. > I can then place the breakpoints back and continue debugging. > > However, the above workaround does not work if I need to debug one of the shared libraries initialization code > > Some info about my environment: > > MinGW 4.6.1 (TDM) 32 bit - I tried the official one 4.7 from MinGW with no luck - the problem persists > GDB 7.05 (note that I tried all versions of gdbs available on MinGW SF download page, from 6.8.5 -> 7.4 with no luck) > Windows 7 64bit > > For comparison: GDB 7.4 on my Ubuntu 12.04 starts the debugging session under 5 seconds for the same application > > Any advise? > > -- > Eran Ifrah > Author of the cross platform, open source C++ IDE: http://www.codelite.org > > Hi, Eran I meet such problem years before, but it was fixed in the gdb trunk months ago. I'm not sure the mingw gdb official 7.4 have this fixed, but from my test, the slow loading problem is already solved. You can try a recent gdb (mostly the gdb build from gdb cvs HEAD) See this report of my test: http://sourceware.org/ml/gdb-patches/2011-11/msg00141.html Here are some messages about the same problem I posted some years ago: http://mingw-users.1079350.n2.nabble.com/Mingw-gdb-pending-breakpoint-on-a-shared-dll-will-slow-downing-loading-time-td5328832.html http://www.digipedia.pl/usenet/thread/12169/1915/ http://sourceware.org/ml/gdb/2010-07/msg00080.html asmwarrior |
From: asmwarrior <asm...@gm...> - 2012-07-21 02:33:54
|
On 2012-7-21 9:46, asmwarrior wrote: > Hi, Eran > > I meet such problem years before, but it was fixed in the gdb trunk months ago. > I'm not sure the mingw gdb official 7.4 have this fixed, but from my test, the slow loading problem is already solved. > You can try a recent gdb (mostly the gdb build from gdb cvs HEAD) > > See this report of my test: > http://sourceware.org/ml/gdb-patches/2011-11/msg00141.html > > Here are some messages about the same problem I posted some years ago: > http://mingw-users.1079350.n2.nabble.com/Mingw-gdb-pending-breakpoint-on-a-shared-dll-will-slow-downing-loading-time-td5328832.html > http://www.digipedia.pl/usenet/thread/12169/1915/ > http://sourceware.org/ml/gdb/2010-07/msg00080.html > > asmwarrior I just checked, and see that the fix is committed in 2011-11-16 http://sourceware.org/ml/gdb-cvs/2011-11/msg00096.html and the gdb 7.4 was branched in:2011-12-13 http://sourceware.org/ml/gdb-announce/2011/msg00005.html So, I believe the fix should already in gdb 7.4, I'm not sure why you still have such issue. Maybe, it is not the one I mentioned. asmwarrior |
From: K. F. <kfr...@gm...> - 2012-07-21 03:38:48
|
Hello Eran and asmwarrior! I have seen something similar with a mingw-w64 build. (I have taken the liberty of cross-posting this reply to the mingw-w64 list.) On Fri, Jul 20, 2012 at 9:46 PM, asmwarrior <asm...@gm...> wrote: > On 2012-7-20 21:10, Eran Ifrah wrote: >> Hello, >> >> I am not sure whether this issue is related to MinGW or to GDB. >> Since I don't have this issue on Linux / Mac and it only happens on Windows 7 + MinGW, I decided to post it here - maybe someone else on this list face this issue I am running a 64-bit mingw-w64 build on 64-bit windows 7, and see slow gdb startup with Qt applications. (I haven't tested whether startup is also slow with simple non-Qt console programs.) >> in the past and can shed some light / provide some good tips on the matter. >> >> Now to the actual problem: >> When I debug my application which consists of many shared libraries ("dll"s, around 35 - 40) and I have a breakpoint set in one of the shared libraries >> the startup time of gdb is *very* slow ( I am talking here about 10 mins ). In my case I do not have pre-set breakpoints. When I run gdb on a small Qt test program, (e.g. "gdb test.exe") the gdb prompt appears essentially immediately, but when I then type "run" it takes about three minutes for the test application to actually launch (i.e., for the gui to appear). Once I get past that slow startup, debugging seems to run normally. >> ... >> Some info about my environment: >> >> MinGW 4.6.1 (TDM) 32 bit - I tried the official one 4.7 from MinGW with no luck - the problem persists >> GDB 7.05 (note that I tried all versions of gdbs available on MinGW SF download page, from 6.8.5 -> 7.4 with no luck) >> Windows 7 64bit In my case I am running: g++ (GCC) 4.7.0 20110829 (experimental) GNU gdb (GDB) 7.3.0.20110829-cvs from a native 64-bit Ruben "personal build" of g++ 4.7.0, and Qt 4.8.0-rc1. (I don't have any reason to think the slow gdb startup is related to Qt -- I just haven't bothered to test it on non-Qt applications.) It is worth noting that this problem first showed up for me (or at least became noticeably worse) recently -- I think the last time I upgraded my compiler / Qt combination. I don't recall, offhand, the g++ build / gdb version that I had been using previously that did not have the slow startup problem (or at least not as badly). >> ... >> Any advise? No, but if anybody gets this issue sorted out, I would love to hear about it. >> ... >> Eran Ifrah >> Author of the cross platform, open source C++ IDE: http://www.codelite.org >> > Hi, Eran > > I meet such problem years before, but it was fixed in the gdb trunk months ago. > I'm not sure the mingw gdb official 7.4 have this fixed, but from my test, the slow loading problem is already solved. As I mentioned above, my gdb version is 7.3.0. > You can try a recent gdb (mostly the gdb build from gdb cvs HEAD) If anybody knows of a recent mingw or mingw-w64 build of gdb that addresses this issue, please chime in. > ... > asmwarrior Thanks for any updates on this problem. K. Frank |
From: asmwarrior <asm...@gm...> - 2012-07-21 04:56:39
|
On 2012-7-21 11:38, K. Frank wrote: > As I mentioned above, my gdb version is 7.3.0. > >> >You can try a recent gdb (mostly the gdb build from gdb cvs HEAD) > If anybody knows of a recent mingw or mingw-w64 build of gdb > that addresses this issue, please chime in. > You can try my build of gdb CVS (32bit) see: http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000 asmwarrior |
From: Eran I. <era...@gm...> - 2012-07-21 07:08:01
|
On Sat, Jul 21, 2012 at 7:59 AM, asmwarrior <asm...@gm...> wrote: > On 2012-7-21 11:38, K. Frank wrote: > > As I mentioned above, my gdb version is 7.3.0. > > > >> >You can try a recent gdb (mostly the gdb build from gdb cvs HEAD) > > If anybody knows of a recent mingw or mingw-w64 build of gdb > > that addresses this issue, please chime in. > > > You can try my build of gdb CVS (32bit) > see: > http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000 > > Thanks. There is one (minor?) problem with your gdb: it seems to requires python installation... and the binaries are quite huge I prefer the current MinGW way packing things: everything in a single directory and there is no need to alter 'PATH' not to mention that python pollutes C:\Windows\ ... (and other places?), which makes it hard to move around my working environment On the bright side, your gdb seems to be the fastest from the all the gdb's I have tested so far. The thing that did the change was changing the workflow a littlet: * start gdb * break at main * place pending breakpoints * continue as opposed to: * start gdb * place pending breakpoints * continue asmwarrior > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > -- Eran Ifrah Author of the cross platform, open source C++ IDE: http://www.codelite.org |
From: Eli Z. <el...@gn...> - 2012-07-21 08:10:06
|
> From: Eran Ifrah <era...@gm...> > Date: Sat, 21 Jul 2012 10:07:31 +0300 > Cc: "K. Frank" <kfr...@pu...>, > min...@li... > > the binaries are quite huge They probably include debug info. Just strip them. |
From: Eran I. <era...@gm...> - 2012-07-21 08:30:35
|
On Sat, Jul 21, 2012 at 11:09 AM, Eli Zaretskii <el...@gn...> wrote: > > From: Eran Ifrah <era...@gm...> > > Date: Sat, 21 Jul 2012 10:07:31 +0300 > > Cc: "K. Frank" <kfr...@pu...>, > > min...@li... > > > > the binaries are quite huge > > They probably include debug info. Just strip them. > Yes, but this was not my main concern, I was more concerned about the python dependency I just gonna have to live with it :) > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > -- Eran Ifrah Author of the cross platform, open source C++ IDE: http://www.codelite.org |
From: asmwarrior <asm...@gm...> - 2012-07-21 15:19:08
|
On 2012-7-21 15:07, Eran Ifrah wrote: > > > On Sat, Jul 21, 2012 at 7:59 AM, asmwarrior <asm...@pu... <mailto:asm...@gm...>> wrote: > > On 2012-7-21 11:38, K. Frank wrote: > > As I mentioned above, my gdb version is 7.3.0. > > > >> >You can try a recent gdb (mostly the gdb build from gdb cvs HEAD) > > If anybody knows of a recent mingw or mingw-w64 build of gdb > > that addresses this issue, please chime in. > > > You can try my build of gdb CVS (32bit) > see: > http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000 > > Thanks. There is one (minor?) problem with your gdb: it seems to requires python installation... and the binaries are quite huge > I prefer the current MinGW way packing things: everything in a single directory and there is no need to alter 'PATH' not to mention that python pollutes C:\Windows\ ... (and other places?), which makes it hard to move around my working environment Yes, the gdb build by me has dependency on python 2.7, but in-fact, you don't need to put python.exe's path in your PATH environment. If I remember correctly, you can just copy "python27.dll" and the folder "Lib", and maybe some msvcrt.dll to your MinGW/bin, the gdb should work fine. And I believe that using this way, the whole gdb package should be portable. I mean the official python27.dll was build from MSVC, so you need some MS crt dlls, besides that, python27.dll will automatically search its own library named "Lib" in the same folder. After such copying, you can safely uninstall your python distribution, because all you needed is copied to MinGW/bin. I'm just a little lazy to package my build gdb with such python files. > > On the bright side, your gdb seems to be the fastest from the all the gdb's I have tested so far. > The thing that did the change was changing the workflow a littlet: > > * start gdb > * break at main > * place pending breakpoints > * continue > > as opposed to: > > * start gdb > * place pending breakpoints > * continue The above two method should not have many difference from my point of view, I know a little about how gdb handling "pending breakpoints", when a new dll loaded, gdb try to see the sources of the dll may matches the pending bps, so it mainly scan all the debug information in the dll. The more dll loaded, the more time you needed. BTW: I usually debug codeblocks(which have 10+ plugins as dlls) under gdb, I see gdb works just fine. (start up quite soon when you have pending bps) asmwarrior |
From: Ruben V. B. <van...@gm...> - 2012-07-21 15:25:43
|
2012/7/21 asmwarrior <asm...@gm...> > On 2012-7-21 15:07, Eran Ifrah wrote: > > > > > > On Sat, Jul 21, 2012 at 7:59 AM, asmwarrior < > asm...@pu... <mailto: > asm...@gm...>> wrote: > > > > On 2012-7-21 11:38, K. Frank wrote: > > > As I mentioned above, my gdb version is 7.3.0. > > > > > >> >You can try a recent gdb (mostly the gdb build from gdb cvs HEAD) > > > If anybody knows of a recent mingw or mingw-w64 build of gdb > > > that addresses this issue, please chime in. > > > > > You can try my build of gdb CVS (32bit) > > see: > > > http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000 > > > > Thanks. There is one (minor?) problem with your gdb: it seems to > requires python installation... and the binaries are quite huge > > I prefer the current MinGW way packing things: everything in a single > directory and there is no need to alter 'PATH' not to mention that python > pollutes C:\Windows\ ... (and other places?), which makes it hard to move > around my working environment > > Yes, the gdb build by me has dependency on python 2.7, but in-fact, you > don't need to put python.exe's path in your PATH environment. > If I remember correctly, you can just copy "python27.dll" and the folder > "Lib", and maybe some msvcrt.dll to your MinGW/bin, the gdb should work > fine. And I believe that using this way, the whole gdb package should be > portable. I mean the official python27.dll was build from MSVC, so you need > some MS crt dlls, besides that, python27.dll will automatically search its > own library named "Lib" in the same folder. > After such copying, you can safely uninstall your python distribution, > because all you needed is copied to MinGW/bin. > > I'm just a little lazy to package my build gdb with such python files. > You can see here<https://github.com/rubenvb/MinGW-w64-build-scripts/blob/master/toolchain/scripts/python.sh>what's needed for Python GDB. My builds<http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/release>come with python-enabled gdb too. Only the python27.dll and the lib/ directory inside "bin" is necessary for correct Qt and Qt Creator functionality. Ruben > > > > On the bright side, your gdb seems to be the fastest from the all the > gdb's I have tested so far. > > The thing that did the change was changing the workflow a littlet: > > > > * start gdb > > * break at main > > * place pending breakpoints > > * continue > > > > as opposed to: > > > > * start gdb > > * place pending breakpoints > > * continue > > The above two method should not have many difference from my point of > view, I know a little about how gdb handling "pending breakpoints", when a > new dll loaded, gdb try to see the sources of the dll may matches the > pending bps, so it mainly scan all the debug information in the dll. The > more dll loaded, the more time you needed. > > BTW: I usually debug codeblocks(which have 10+ plugins as dlls) under gdb, > I see gdb works just fine. (start up quite soon when you have pending bps) > > asmwarrior > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: K. F. <kfr...@gm...> - 2012-07-21 15:24:22
|
Hi asmwarrior! Thanks for the link to your gdb build. On Sat, Jul 21, 2012 at 12:59 AM, asmwarrior <asm...@gm...> wrote: > > On 2012-7-21 11:38, K. Frank wrote: >> >> As I mentioned above, my gdb version is 7.3.0. >> >>> >You can try a recent gdb (mostly the gdb build from gdb cvs HEAD) >> >> If anybody knows of a recent mingw or mingw-w64 build of gdb >> that addresses this issue, please chime in. >> > You can try my build of gdb CVS (32bit) There's one point I'm not certain of: I assume -- perhaps incorrectly -- that I will need a 64-bit build of gdb to debug 64-bit executables. As I understand it, the application being debugged runs in-process inside of gdb. Is this true, or can I freely mix a 32-bit gdb with 64-bit applications (and vice versa)? > see: > http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000 > > asmwarrior Thanks for your help. K. Frank |
From: asmwarrior <asm...@gm...> - 2012-07-21 15:29:17
|
On 2012-7-21 23:24, K. Frank wrote: > > There's one point I'm not certain of: > > I assume -- perhaps incorrectly -- that I will need a 64-bit build > of gdb to debug 64-bit executables. As I understand it, the > application being debugged runs in-process inside of gdb. Is > this true, or can I freely mix a 32-bit gdb with 64-bit applications > (and vice versa)? > I have no experience of 64bit gdb nor 64bit executables. All of my system/application is 32bit. So, I can't say much, sorry. If I remember correct, there are some 64bit gdb from qt/qtcreator's site. asmwarrior |