[Qt-creator] Debugging in Win32

André Pönitz apoenitz at trolltech.com
Fri Nov 7 11:40:27 CET 2008


On Wednesday 05 November 2008 13:49:09 ext Greg Santucci wrote:
> Thanks for the information about gdb Andre', I didn't think that the
> breakpoint in the constructor bug would still be a problem with gdb after so
> many years.
> 
> I've confirmed that gdb works when breakpoints are set anywhere else - I
> added some UI elements, and set breakpoints in other places, and it works
> fine. Qt Creator is excellent.
> 
> One final nitpick though - the debugger in the Eclipse Qt plugin (which uses
> MingW gcc/gdb) is much faster. After placing a breakpoint in a button click
> handler, eclipse breaks to the debugger almost instantly, whereas in Qt
> Creator there is a ~6 second delay. 

> Is it because of the Qt types parsing? 
> Is there a way to turn this feature off to speed up the debugger?

I am not quite sure I understand the scenario you describe. Especally
a 6 sec delay is strange unless it's the time when debug information
for the big shared libraries are loaded by gdb.

However, as you mention "types": "typeless" information for function
parameters is provided by gdb as soon as it stops due to a breakpoint.
Eclipse does seem to use that and be contend with it,  I am not.

I do not think a displayed value of "{...}" is useful, also with C++ being
a typed language, type information is important at least for me.

To get type information I need an extra roundtrip to gdb, and if it turns
out to be something "interesting" I need an extra round trip through gdb
to call the custom dumpers. Each roundtrip costs, say, 50 ms.

I'll have a look whether per-frame caching of type information or reordering
operations may speed up things. It would be nice if you could describe
the scenario in a bit more detail and send a complete small project that
I could use to reproduce the problem.

Thanks for the report,
Andre'



More information about the Qt-creator-old mailing list