avoid -break-list calls

[Vladimir Prus]

On Friday 26 June 2009 Niko Sams wrote:

> Hi,
> 
> I'm trying to make stepping in the debugger faster by avoiding unneded commands.
> So far stack view and variable view is only updated when they are shown.
> 
> But -break-list (returns all breakpoints) still is there.
> Afaik it is needed because the user can insert/remove/modify breakpoints using
> the gdb view. If the user executes "break main.cpp:12" this breakpoint
> is automatically
> added to the breakpoint widget.
> Problem: this happens not immideately but after the next debugger break.
> 
> What could we do:
> 1. remove -break-list completely. If the user inserts custom
> breakpoints he doesn't
> have to see them in the breakpoint widget. This is a problem if the
> user changes/deletes
> breakpoints that kdevelop inserted. I don't think that users will use
> gdb view to modify
> breakpoints commonly.

I am not happy with this approach. Many KDevelop users are coming from
console, and therefore will be upset if GDB console is some second-class
citizen not integrated with anything. 

> 2. call -break-list only after the user executed a command in the gdb
> view. We could
> even sniff for break commands and do the update only after such a command.

I think sniffing might work or might not, depending on whether we expect
user-defined GDB commands (also known as macros) to be used. 

> 3. leave like it is but execute -break-list only if the user executed
> a command using
> gdb view. (doesn't solve the problem mentioned above).
> 
> 4. leave everything like it is because -break-list is needed for
> something else I missed.

I think the first thing it to modify gdb startup sequence to emit

	-enable-timings yes

This will cause GDB to report the time it took to execute every command,
and we'll be able to see if any command is worth optimizing. I suspect
that -break-list is not worth optimizing, because it is not talking to
the target, but directly returns the current state of gdb breakpoint table.

I think that we should also emit -break-list after each command send
in the GDB  console. I think that KDevelop3 used to reload all state
after user commands. This however, does not eliminate the need to
set -break-list after each stop, because we need to update the hit
counts, and because after each stop, some breakpoints can become resolved,
and some breakpoints can become unresolved again.

- Volodya