On 2012-7-21 15:07, Eran Ifrah wrote:
>
>
> On Sat, Jul 21, 2012 at 7:59 AM, asmwarrior 
> <asmwarrior-re5jqeeqqe8avxtiumw...@public.gmane.org 
> <mailto:asmwarr...@gmail.com>> 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

------------------------------------------------------------------------------
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to