--14dae9340c49d9701e04c5589f94
Content-Type: text/plain; charset=UTF-8
Post by asmwarriorOn Sat, Jul 21, 2012 at 7:59 AM, asmwarrior <
Post by K. FrankAs I mentioned above, my gdb version is 7.3.0.
Post by asmwarriorYou 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)
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
Post by asmwarriorOn the bright side, your gdb seems to be the fastest from the all the
gdb's I have tested so far.
* start gdb
* break at main
* place pending breakpoints
* continue
* 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
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--14dae9340c49d9701e04c5589f94
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable <div class="gmail_quote">2012/7/21 asmwarrior <span dir="ltr"><<a href="mailto:***@gmail.com" target="_blank">***@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2012-7-21 15:07, Eran Ifrah wrote:<br> <div class="im">><br>
><br>
> On Sat, Jul 21, 2012 at 7:59 AM, asmwarrior <<a href="mailto:asmwarrior-***@public.gmane.org">asmwarrior-***@public.gmane.org</a> <mailto:<a href="mailto:***@gmail.com">***@gmail.com</a>>> wrote:<br>
><br>
> On 2012-7-21 11:38, K. Frank wrote:<br>
> > As I mentioned above, my gdb version is 7.3.0.<br>
> ><br>
> >> >You can try a recent gdb (mostly the gdb build from gdb cvs HEAD)<br>
> > If anybody knows of a recent mingw or mingw-w64 build of gdb<br>
> > that addresses this issue, please chime in.<br>
> ><br>
> You can try my build of gdb CVS (32bit)<br>
> see:<br>
> <a href="http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000" target="_blank">http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000</a><br>
><br> </div>> Thanks. There is one (minor?) problem with your gdb: it seems to requires python installation... and the binaries are quite huge<br>
> 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<br>
<br>
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.<br>
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.<br>
After such copying, you can safely uninstall your python distribution, because all you needed is copied to MinGW/bin.<br>
<br>
I'm just a little lazy to package my build gdb with such python files.<br></blockquote><div><br>You can see <a href="https://github.com/rubenvb/MinGW-w64-build-scripts/blob/master/toolchain/scripts/python.sh">here</a> what's needed for Python GDB. <a href="http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/release">My builds</a> 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.<br>
<br>Ruben<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> On the bright side, your gdb seems to be the fastest from the all the gdb's I have tested so far.<br>
> The thing that did the change was changing the workflow a littlet:<br>
><br>
> * start gdb<br>
> * break at main<br>
> * place pending breakpoints<br>
> * continue<br>
><br>
> as opposed to:<br>
><br>
> * start gdb<br>
> * place pending breakpoints<br>
> * continue<br>
<br>
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.<br>
<br>
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)<br>
<div class="HOEnZb"><div class="h5"><br>
asmwarrior<br>
<br>
------------------------------------------------------------------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<br>
will include endpoint security, mobile security and the latest in malware<br>
threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>
_______________________________________________<br>
Mingw-w64-public mailing list<br>
<a href="mailto:Mingw-w64-***@lists.sourceforge.net">Mingw-w64-***@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/mingw-w64-public" target="_blank">https://lists.sourceforge.net/lists/listinfo/mingw-w64-public</a><br>
</div></div></blockquote></div><br>
--14dae9340c49d9701e04c5589f94--