avoid -break-list calls

[Niko Sams]

On Sat, Jun 27, 2009 at 10:39, Vladimir Prus<ghost at cs.msu.su> wrote:
> 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.
-break-list that returns 6 breakpoints:
time={wallclock="0.00129",user="0.01000",system="0.00000"}
...not that much.

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

> 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


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?

Niko