debugger plans for kdevelop 4
ghost at cs.msu.su
Mon Jul 17 05:52:53 UTC 2006
On Saturday 15 July 2006 23:55, Nick Savoiu wrote:
> While there has been an improvement in the frame stack
> update/display it's still not quite on par with, say,
> the one in Visual Studio 2005.
> The projects that I debug often have more than 60-70
> frames in the stack and stepping gets quite bogged
KDevelop should get no more that 30 frames initially.
> Part of the problem might be the fact the GDB is
> not tightly coupled with KDevelop.
No, this has something to do with inefficient gdb code, and nothing else.
I've talked briefly with gdb maintainers, but this boils down to getting
accurate profiling info and optimising.
> Maybe a mechanism by which the top frame is quickly
> obtained and the UI updated accordingly (mainly source
> position). The rest of the frames then are filled out
> by a lower priority background thread such that if one
> does not care about them they don't get in the way.
This should be almost this way already, except that all UI is disabled until
full refetch is done. I was asked (and plan) to disable UI only when gdb is
actually running the program, but had no time.
More information about the KDevelop-devel