Re: breakpoint extension for remote protocol, take II

[Andrew Cagney <ac131313@cygnus.com>]

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> Have you considered what to do when there is a choice of
> Andrew> software breakpoints?  Jim Ingham's pointed out to me that in
> Andrew> the case of the MIPS/MIPS16 and ARM/THUMB the breakpoint might
> Andrew> be 2 bytes or 4 bytes in size (and the value different in each
> Andrew> case).
> 
> 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.

FYI,  I can't see how a stub can determine the breakpoint size/type from
just the address.  As it is GDB has enough trouble - in the case of the
ARM, GDB ends up using symbol table information.

I've also been doing some research into the ``B'' and ``b'' packets.
While the stubs found in gdb/*stub.c don't support ``b'' or any other
``B'' packet there are other stubs (non GPL'd) that do reconize it :-(

	Andrew