Re: breakpoint extension for remote protocol

["J.T. Conklin" <jtc@RedBackNetworks.com>]

> > FYI, there is already a semi-official use of `B' as a generic remote
> > breakpoint operation.  The syntax is:
> > 
> >     B<address>,S    Set a breakpoint
> >     B<address>,C    Clear a breakpoint
> 
> Where is this used?  I see no evidence of this in devo's remote.c.
> Is it hiding out on a branch somewhere?  FYI, the syntax is bogus.
> It should use B and b like the rest of the commands.  

Although I noticed the parallelism of the existing commands g/G, m/M,
and I recently proposed p to compliment P; I used B/D instead of b/B
because inserting and removing breakpoints don't have quite the same
type of symmetry as reading and writing memory or registers.  A read
command doesn't change the state of the target, while removing a
breakpoint certainly does.

One issue with 'b' is that it's used in the sparc* stubs to set the
baud rate of the connection.  That code has been #ifdef'd out with 
the comment "Disabled until we can unscrew this properly", so we may
be able to simply junk that.

Nevertheless if it is thought that b/B should be used, I'll make that
change.  I could roll out breakpoint support within RedBack tomorrow,
but that would be less than optimal if I had to deal with supporting
multiple versions of GDB for different releases of our software.  It's
in my interest to get the protocol extensions nailed down and agreed
upon before I deploy it (and get it contributed).

> > With regard to the general question of extending the remote-gdb protocol
> > so that it supports a generic hardware breakpoint mechanism.  I agree it
> > is needed.  It is a missing part of the overall toolkit.
> 
> I have discussed this with GDB folk in the past.  If you want to hear what
> needs to be done, ping me.

Stu, I think I implemented your design faithfully.  However, it was from 
memory of a two year old conversation.  If I've left something out, please
let me know.

>  > Did you know
>  > that some targets actually implement hardware breakpoints by poking the
>  > registers directly?
> 
> Yes, and this is a complete sin.

A related sin which needs to be addressed is that there can be only
one set of hardware watchpoint and breakpoint functions (ie. they're
not in the target vector).  Now that the remote protocol can support
hardware break/watchpoints, we'll need to fix that.

	 --jtc