debugger plans for kdevelop 4

[Vladimir Prus]

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
> down. 

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.

- Volodya