Re: one proposal ... `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT ??

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Masahiro" == Masahiro Fukuda <masahiro@lsi.nec.co.jp> writes:
Masahiro> My name is Masahiro Fukuda.  Independently, I added some
Masahiro> keyword (actually [B/b] just like J.T.C did) into gdb serial
Masahiro> protocol in order to transmit "breakpoint" to gdbserver
Masahiro> instead of writing TRAP instruction.

Masahiro> Some arguements including <addr>, <length>, <ignore_count>
Masahiro> follow breakpiont keyword in my code.  Those command packets
Masahiro> are generated in v850_insert_hw_breakpint()/
Masahiro> v850_insert_watchpoint() in v850-tdep.c.

I didn't think about breakpoints with ignore counts when developing
the breakpoint extension proposal.  I did want to allow the stub to
manage thread specific breakpoints, which are similar.  I also spent
some time thinking about how to support conditional breakpoints.  My
current thoughts are to use an easily parsed stack based expression
syntax, but I'm not actively pursuing this feature.

The problem with breakpoints with ignore counts is the synchronization
of the count between GDB and the stub.  As I understand your proposal,
you address this by having the 'remove breakpoint' command return how
many counts are left for each breakpoint.

Unfortunately, I believe that this conflicts with another project that
I'm working on.  I've been changing GDB so that breakpoints are not
inserted or removed from the target unless it is absolutely necessary
to do so.

At present, whenever you step through code, the active breakpoints are
inserted, the code is executed, then the breakpoints are removed.  If
the user is using a lot of breakpoints, this greatly increases the
time it takes to step through code.

If GDB must sync ignore counts by removing breakpoints, that precludes
this optimization.  Perhaps an additional command that lists managed
breakpoints and their ignore count (if any) is needed.

Another possible problem is that our current model is that duplicate
breakpoints are ignored when they are inserted.  A breakpoint is
uniquely defined by <type>, <addr>, <len>, and possibly <thread-id> if
threads specific breakpoints are supported.  But how can the stub tell
the differences between two breakpoints when the only difference is
the ignore count?  This may require the stub to return a handle when a
breakpoint is inserted so that GDB can uniquely identify it.

I'm not saying this is a bad idea.  Actually, this is the kind of
thing a stub can keep track of fairly trivally yet greatly reduce 
the amount of debug protocol overhead.  But I think it needs a bit 
more refinement.

Thoughts?

        --jtc

-- 
J.T. Conklin
RedBack Networks