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

You can see here what's needed for Python GDB. My builds 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public