Re: breakpoint extension for remote protocol, take II

[Andrew Cagney <ac131313@cygnus.com>]

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> >> I was unaware processors with multiple software breakpoints
> >> existed.  I assume that the 2 byte breakpoint instructions have to
> >> be inserted in "high-density" code segments and 4 byte breakpoints
> >> insns have to be inserted in "low-density" segments.
> >>
> >> We can almost get away without specifying breakpoint types.  Since
> >> in most cases the stub is bound into the executable, thus can
> >> determine whether the breakpoint is within a high or low density
> >> code segment.  However, this would not be suitable for applications
> >> like monitors with a remote protocol front end, as those would not
> >> have any prior knowledge of an arbitrary program's memory map.
> 
> Andrew> FYI, I can't see how a stub can determine the breakpoint
> Andrew> size/type from just the address.  As it is GDB has enough
> Andrew> trouble - in the case of the ARM, GDB ends up using symbol
> Andrew> table information.
> 
> I was thinking of a situation where the linker script adds special
> symbols at the beginning and end of the high and low density code
> segments, and the stub compares the breakpoint address with those
> symbols.  This will work in a self contained executable, but not if
> any code is loaded dynamically.
> 
> Andrew> I've also been doing some research into the ``B'' and ``b''
> Andrew> packets.  While the stubs found in gdb/*stub.c don't support
> Andrew> ``b'' or any other ``B'' packet there are other stubs (non
> Andrew> GPL'd) that do reconize it :-(
> 
> Bleh.  But that's what the 'q' escape is for.  IMO, all experimental
> protocol extensions should be using 'q'; likewise, GDB should never
> use 'q' itself.  But since GDB uses 'q', a stub using 'B' or 'b' is
> not surprising.

I'd like to propose that:


	o	the breakpoint protocol be made official
		using the ``z/Z'' character (think cntrl-z)

		GDB would also get a command allowing it to
		use ``b/B'' as a compatibility character.

		DOES ANYONE OBJECT TO ``[zZ]''?


	o	the ``,LLLL'' be made non-optional.

		For software breakpoints it would indicate
		the size of the instruction (in hex bytes)
		that needs to be patched.

		J.T. would this break your existing stub code?


	o	the ``LLLL'' for hardware-breakpoints and
		watchpoints be clarified to explain that it
		indicates the region to be watched.


For reference, J.T.'s original proposal (version II) is appended.

	Andrew


    insert break    Bt,AA..AA[,LLLL]
    or watchpoint                   t is type: 0 - software breakpoint, 
                                    1 - hardware breakpoint, 2 - write
                                    watchpoint, 3 - read watchpoint, 4 -
                                    access watchpoint;
                                    AA..AA is address;
                                    LLLL is number of bytes
    reply           OK              for success
                    ENN             for an error
    (not supported by all stubs).
                                    
    remove break    bt,AA..AA[,LLLL]
    or watchpoint                   t is type: 0 - software breakpoint, 
                                    1 - hardware breakpoint, 2 - write
                                    watchpoint, 3 - read watchpoint, 4 -
                                    access watchpoint;
                                    AA..AA is address;
                                    LLLL is number of bytes
    reply           OK              for success
                    ENN             for an error
    (not supported by all stubs).