Re: breakpoint extension for remote protocol, take II

[jtc@redback.com (J.T. Conklin)]

>>>>> "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.

	--jtc

-- 
J.T. Conklin
RedBack Networks