[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