breakpoint extension for remote protocol

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

I've been tasked to add support for hardware watch/breakpoints over
the remote protocol.  

This is what I'm thinking so far: A create breakpoint command would
insert a breakpoint insn or set the appropriate debug registers.  A
cooresponding delete breakpoint command would remove a breakpoint.

Having stubs manage their own breakpoints may even be adventageous for
systems without hardware breakpoints.  As GDB inserts breakpoint insns
directly in the text segment, it requires the text segment to be read/
write.  Errors that would ordinarily cause an exception could pass
unnoticed.  The mem write command could be modified to write enable
the page, copy the data, and then write protect it again; but doing
those protection modifications only when breakpoints are inserted and
removed protects the user from inadvertantly using GDB to modify read
only data.

This of course, would require the stubs to keep track of more
information.  In many cases allocating breakpoint contexts dynamically
would be impossible or undesirable (it is likely that you couldn't use
the same dynamic memory allocator as the rest of the system (if indeed
such a facility was available) as it wouldn't be safe to use in an
interrupt/exception context).  As such, the protocol will have to have
a mechanism to indicate that all available breakpoints have been
allocated.  This is probably not much of a concern, since ROM monitors
and hardware watch/breakpoint registers have similar constraints.  I'd
like to not limit the number of contexts to a fixed number, as some
systems/debugging situations may need many more than others.

Here is the protocol elements that I'm currently working with:

    Insert Breakpoint:	   B<type>,<address>[,<length>]
    returns:		   ??	- A cookie representing the breakpoint
			   EX	- breakpoint type not supported
				- no breakpoint contexts available
				- invalid/unsupported address
				- invalid/unsupported length

    Remove Breakpoint:	   D<cookie>
    returns:		   OK	- breakpoint removed
			   EX	- breakpoint <cookie> not found


    <type>		   'r', 'w', 'x' for read, write, or execute.
    <address>		   A target address
    <length>		   1, 2, or 4; number of bytes for read or 
			   write watchpoint.

When the target is started (step, continue), the stub is responsible
for installing breakpoints instructions.  Likewise, when the stub
regains control, it is responsible for removing breakpoints.

	--jtc