avoid -break-list calls

[Vladimir Prus]

On Saturday 27 June 2009 Niko Sams wrote:


> >> 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.
> -break-list that returns 6 breakpoints:
> time={wallclock="0.00129",user="0.01000",system="0.00000"}

Interesting, user time is more than wallclock time. I wonder if that's
because user time is in 1/100 of seconds.

> ...not that much.
> 
> But there is still the overhead for the whole sending the command invoking
> handler and so on.

I suspect, in no scientific way, that the time actually spend in KDevelop is
also very small. I am not sure if the roundtrip over pipe adds significant 
overhead -- and I don't know how to measure that.

> 
> > 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.
> yes, the user could even step or something.
> 
> > 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.
> Of course -  I didn't think about that.
> 
> So the conclulsion is that we leave it like it is :D

Ok :-)

> A different thought: QtCreator has a "Discardable" flag plus a
> "Discards" flag for every command.
> A Step command can discard commands that reload the state that way.
> Do you think it's worth the work?

This might actually be reasonable. I am not sure how those flags work
in QtCreators but it seems worthwhile to separate 'state updating'
commands, and whenever commands line 'step' are emitted

- Remove state updating commands from the queue
- Ignore results of commands that are already send to GDB

In fact, GDB now has *running notification, which is probably the most
reliable indicator that we need to discard state updating commands -- because
this notification is emitted by GDB core in all cases when target is run,
including CLI commands and macros.

- Volodya