Re: breakpoint extension for remote protocol, take II

Re: breakpoint extension for remote protocol, take II

[J.T. Conklin]

>>>>> "Toshiyasu" == Toshiyasu Morita <tm@netcom.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.

Toshiyasu> Is there a four-byte sequence which is an illegal
Toshiyasu> instruction in both MIPS16 and MIPS32 modes?

Even if there were, I don't think it would work.

If you installed this four byte sequence in a 16 bit code segment at
0x1000, it would also overwrite the instruction at 0x1002.  If that
instruction is a branch target, bad things are likely to happen.  A
bit of compiler support to insert a nop before branch targets could
possibly make this work, but that would diminish any benefit high
density instructions are supposed to offer.

	--jtc

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Mon Jun 14 18:01:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Testsuite Organization Proposal
Date: Mon, 14 Jun 1999 18:01:00 -0000
Message-id: <3765A5CE.E9C8B0E9@cygnus.com>
References: <199906142351.QAA06182@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00170.html
Content-length: 1173

Stan Shebs wrote:
> 
> I'd like to propose a semi-formalization of the current testsuite
> organization, basically just reflecting current practice, but with
> enough precision to guide further additions.  The testsuite is key for
> GDB developers; the breadth of functionality and platforms is now so
> broad, in many cases, users won't discover regressions for months or
> years after the change that caused them; while a testsuite run often
> reveals mistakes right away.
> 
> First of all, testsuite organization mainly serves the purpose of
> intelligibility; DejaGNU finds all the expect scripts wherever they're
> placed.  But with around 6000 tests in all, it becomes important to
> organize them sensibly.
> 
> gdb.base        This is the base testsuite.  The tests in it should
>                 apply to all configurations of GDB (but generic
>                 native-only tests may live here).  The test programs
>                 should be in a subset of C that is valid K&R, ANSI/ISO,
>                 and C++ (ifdefs are allowed).

I'd kind of like to see gdb.base contain no C++ tests.  There are
targets out there that don't have a C++ compiler.

	Andrew
From ac131313@cygnus.com Mon Jun 14 18:13:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: breakpoint extension for remote protocol, take II
Date: Mon, 14 Jun 1999 18:13:00 -0000
Message-id: <3765A855.5EF176AF@cygnus.com>
References: <199906142359.QAA06291@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00171.html
Content-length: 1140

Stan Shebs wrote:
> 
>    Date: 14 Jun 1999 16:47:32 -0700
>    Lines: 39
> 
>    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.
> 
> You mean like with qOffsets, that's been standardly issued by GDB for
> years? :-)

And QCrc.  I've just had this one pointed out to me ....

> Actually, I don't ever remember hearing that 'q' was supposed to be
> experimental, and the existing docs don't seem to say so either.  At
> this point we would have to pick a different char I think, and be very
> disciplined about not allowing any usages of it into the standard
> sources, so that it really can be for experimentation.

I'd like to seriously propose that:

	[qQ][A-Z].*

be reserved for GDB's internal use while:

	[qQ][a-z].*

be declared as available for custom jobs.  In addition, custom packets
include a clearly reconisable identifier vis:

	qcygnus.badhack


> In general, we have a sizeable documentation gap with the remote
> protocol; it's become so ubiquitous it ought to have its own RFC... :-)

Comming ...

	Andrew
From ac131313@cygnus.com Mon Jun 14 19:00:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Unused remote protocol letters?
Date: Mon, 14 Jun 1999 19:00:00 -0000
Message-id: <3765B333.6B886FB7@cygnus.com>
References: <199906142359.QAA06291@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00172.html
Content-length: 237

Hello,

Using pencil and paper and a glance through several sources I think the
following letters (upper and lower case) havn't been taken yet:

	a, e, f, i, j, l, n, o, u, v, w, y, z

Anyone care to concure with this?

	Andrew
From ac131313@cygnus.com Mon Jun 14 19:15:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Unused remote protocol letters?
Date: Mon, 14 Jun 1999 19:15:00 -0000
Message-id: <3765B4B6.32B11EA7@cygnus.com>
References: <199906142359.QAA06291@andros.cygnus.com> <3765B333.6B886FB7@cygnus.com>
X-SW-Source: 1999-q2/msg00173.html
Content-length: 426

Andrew Cagney wrote:
> 
> Hello,
> 
> Using pencil and paper and a glance through several sources I think the
> following letters (upper and lower case) havn't been taken yet:
> 
>         a, e, f, i, j, l, n, o, u, v, w, y, z
> 
> Anyone care to concure with this?

(Following up to ones own e-mail ...)

``A'' is apparently the arguments packet...

Lets try:

	e, f, i, j, l, n, o, u, v, w, y, z

	Andrew
From jsm@cygnus.com Mon Jun 14 22:59:00 1999
From: Jason Molenda <jsm@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Old GDB releases are now available by anon-ftp
Date: Mon, 14 Jun 1999 22:59:00 -0000
Message-id: <19990614225906.A3608@cygnus.com>
X-SW-Source: 1999-q2/msg00174.html
Content-length: 660

I have put a collection of old GDB releases on-line at

	ftp://sourceware.cygnus.com/pub/gdb/releases/ANCIENT/

I have collected GDB releases going back to GDB 2.4, released in January,
1988.  I think I have most of them from about 3.4 and on.  Earlier than
3.4, I'm missing many of the releasees.

These old releases are completely useless on modern hardware, don't
even think about using any of them.  Every so often someone needs to
look into an old version of GDB for some reason or another; this archive
should be helpful for those people.

If you have any old gdb releases sitting around that I do not have in
this collection, please let me know.

Jason
From brendan@dgs.monash.edu.au Tue Jun 15 17:11:00 1999
From: Brendan Simon <brendan@dgs.monash.edu.au>
To: binutils <binutils@sourceware.cygnus.com>, Dan Malek <dmalek@jlc.net>, Magnus Damm <eramdam@kieray1.p.y.ki.era.ericsson.se>, gdb <gdb@sourceware.cygnus.com>
Subject: Using objdump to force a section to load with gdb.
Date: Tue, 15 Jun 1999 17:11:00 -0000
Message-id: <3766EA73.123505A6@dgs.monash.edu.au>
X-SW-Source: 1999-q2/msg00175.html
Content-length: 2181

I have a linux kernel compiled for a mpc860 target and am trying to get
it to run by downloading it into memory using a background debugger
(BDM).  The boot code gets to the point where it trys to uncompress the
kernel but fails because the image isn't loaded into memory (only .text,
.rodata and .data are loaded).  I tried using objcopy to set the "image"
section to "load" but it does not seem to work.  How can I get gdb to
load the image section (either using a gdb command or binutils) ?

Thanks,
Brendan Simon.

Here is a before/after trace using objcopy --set-section-flags.  As you
can see, the load attribute is not set.  I've tried all combinations of
attributes but I can't get it to work.  Am I doing something wrong ?

powerpc-linux-objdump --section-headers myzimage
myzimage:     file format elf32-powerpc
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00004324  00100000  00100000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00000460  00104330  00104330  00014330  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         000002f8  00105000  00105000  00015000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0000bbac  00106000  00106000  00016000  2**2
                  ALLOC
  4 image         0006ccbf  00000000  00000000  00016000  2**0
                  CONTENTS, READONLY

powerpc-linux-objcopy --set-section-flags=image=load myzimage

powerpc-linux-objdump --section-headers myzimage
myzimage:     file format elf32-powerpc
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00004324  00100000  00100000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00000460  00104330  00104330  00014330  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         000002f8  00105000  00105000  00015000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0000bbac  00106000  00106000  00016000  2**2
                  ALLOC
  4 image         0006ccbf  00000000  00000000  00016000  2**0
                  CONTENTS

Re: breakpoint extension for remote protocol, take II

[Jim Blandy]

> > Actually, I don't ever remember hearing that 'q' was supposed to be
> > experimental, and the existing docs don't seem to say so either.  At
> > this point we would have to pick a different char I think, and be very
> > disciplined about not allowing any usages of it into the standard
> > sources, so that it really can be for experimentation.
> 
> I'd like to seriously propose that:
> 
> 	[qQ][A-Z].*
> 
> be reserved for GDB's internal use while:
> 
> 	[qQ][a-z].*
> 
> be declared as available for custom jobs.  In addition, custom packets
> include a clearly reconisable identifier vis:
> 
> 	qcygnus.badhack


Does reserving prefixes for internal/custom/official packets really
help?  You never know what's going to become popular, and once
something does, it's too late to change all the random ROMS out there
to expect a different letter, just to indicate the packet's new
legitimacy.  Those are the forces carrying the design now, right?

If we're going to establish a policy, it should be one that allows a
smooth transition of packets' status from "experimental" to
"standard".  By `smooth', I mean that the packet itself shouldn't have
to change simply because we've acknowledged it as widely useful.

Here's another proposal, which does allow smooth transitions: make the
GDB maintainer responsible for allocating unique prefixes to anyone
who asks for one, like the IANA.  Put a comment in remote.c suggesting
that people extending the protocol ask for a prefix.

When a packet becomes popular, the GDB maintainer documents it.  No
code changes.

Note that there's no point in having a designated experimentation
prefix, since that has exactly the problem we're trying to avoid.

Maybe we can list existing allocated prefixes in remote.c too, so
people can say, "Oh!  My company already has a prefix!"  If the list
gets large, we can move it elsewhere.

I don't think we'll need to worry about abuse.  We are talking about
GDB's remote protocol here, not domain names.
From ac131313@cygnus.com Wed Jun 16 16:30:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: breakpoint extension for remote protocol, take II
Date: Wed, 16 Jun 1999 16:30:00 -0000
Message-id: <37683355.CB8547BD@cygnus.com>
References: <199906142359.QAA06291@andros.cygnus.com> <3765A855.5EF176AF@cygnus.com> <np7lp3etym.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q2/msg00177.html
Content-length: 2606

Jim Blandy wrote:

> Does reserving prefixes for internal/custom/official packets really
> help?  You never know what's going to become popular, and once
> something does, it's too late to change all the random ROMS out there
> to expect a different letter, just to indicate the packet's new
> legitimacy.  Those are the forces carrying the design now, right?

I think it would.  There are actually a number of problems and I guess
I'm only addressing one of them.

The specific case I was thinking of was where a user wanted to enable
the querying/setting of things their specific target.

Another way to go would be to allow the protocol to tunnel generic
target monitor commands across.  I've seen several requests for this.


> If we're going to establish a policy, it should be one that allows a
> smooth transition of packets' status from "experimental" to
> "standard".  By `smooth', I mean that the packet itself shouldn't have
> to change simply because we've acknowledged it as widely useful.
> 
> Here's another proposal, which does allow smooth transitions: make the
> GDB maintainer responsible for allocating unique prefixes to anyone
> who asks for one, like the IANA.  Put a comment in remote.c suggesting
> that people extending the protocol ask for a prefix.

Yes, control mechanisms probably shouldn't be using the query packet.

> When a packet becomes popular, the GDB maintainer documents it.  No
> code changes.

One problem we've got now (for breakpoints/baud) is that there are
boards in the field that know about a `B' packet and it isn't the one
proposed.  If we send that board the new B packet it will accept it as
an old B packet fool GDB into thinking that that it has a modern board
:-(

Hmm, perhaphs GDB's startup should be doing an initial query that
returns a string indicating everything the board suports.  Something
like:

	<- QProtocol
	<- !1B1b1...

where the returned string consists of:

	{ <PACKET><VERSION-NUMBER> }

(``!1'' could be interpreted as extended remote).

> Note that there's no point in having a designated experimentation
> prefix, since that has exactly the problem we're trying to avoid.
> 
> Maybe we can list existing allocated prefixes in remote.c too, so
> people can say, "Oh!  My company already has a prefix!"  If the list
> gets large, we can move it elsewhere.

Good point.

Things to do inclues deleting the protocol description from every
remote*.c and *stub.c file I find and moving a summary to gdb/doc/

> I don't think we'll need to worry about abuse.  We are talking about
> GDB's remote protocol here, not domain names.

Andrew
From ac131313@cygnus.com Wed Jun 16 17:00:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: GDB-Protocol: Cycle step command?
Date: Wed, 16 Jun 1999 17:00:00 -0000
Message-id: <376838C8.D287322C@cygnus.com>
X-SW-Source: 1999-q2/msg00178.html
Content-length: 574

Hello,

I'd like to propose that the GDB remote protocol be extended to support
a cycle step command.  This command would be used when either
interacting with physical control devices such as JTAG or (more often)
cycle accurate simulators.

Possible syntaxes include:

	QCycle=<NR>
and	i<NR>

comments suggestions additional data people thing may be needed.  Unlike
the ``S'' and ``C'' commands I've not included an address.  Changing the
address in a cycle accurate model can get very complex.

Exactly what a cycle is would be target dependant.

	Andrew
From ac131313@cygnus.com Wed Jun 16 17:15:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: GDB-Protocol: Script command
Date: Wed, 16 Jun 1999 17:15:00 -0000
Message-id: <37683D95.38453A42@cygnus.com>
X-SW-Source: 1999-q2/msg00179.html
Content-length: 787

When debugging both embedded targets and simulators there is often the
need to pass across target specific commands.  As an example, GDB, when
talking to a builtin simulator, allows `sim' commands:

	(gdb) target sim
	Connected to simulator
	(gdb) load
	....
	(gdb) sim trace instruction on
	(gdb) run
	0x12432: ld r1, r2
	...

There is no corresponding mechanism available in the remote protocol. 
I'd like to propose that the ``qS'' prefix be reserved for this:

	<- qS<some-command>
	-> output-from-command

(Well another posibility would be ``QScript=<command>''.)  Potential
issues include:

	o	encoding of special charcters
		(should we just pass hex?).

	o	security

	o	the corresponding GDB command
		(I've no idea, suggestions welcome).


	Andrew
From ac131313@cygnus.com Wed Jun 16 17:30:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: GDB-Protocol: Version/Protocol packet
Date: Wed, 16 Jun 1999 17:30:00 -0000
Message-id: <37684175.A8867983@cygnus.com>
X-SW-Source: 1999-q2/msg00180.html
Content-length: 447

Hello,

As a starting point, I'd like to put forward:

	<- qVersion
	-> { <prefix><version> }

<prefix> ::=

	All prefix letters and strings reconized by the monitor vis:
	S
	qCRC
	qL qP qC

<version> ::=
	A version integer as an identifier of changed packets.

For example, a theoritical response might be:

	-> B1b1qL1qP1qC1QVersion1....

while a newer target might respond with:

	-> B2b2qL1qP1qC1QVersion1....

Andrew
From shebs@cygnus.com Wed Jun 16 17:37:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Cygnus to release GDBtk/Insight to the net
Date: Wed, 16 Jun 1999 17:37:00 -0000
Message-id: <199906170037.RAA18779@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00181.html
Content-length: 1505

Hi everybody, Cygnus is planning to release Insight(tm) to the net.
If the name doesn't mean anything to you, this is the 1997 rewrite, in
[incr tcl], of the old tcl/tk GUI to GDB.  Although architecturally
similar to the previous version, the rewrite is much improved
usagewise; it is much more like a real GUI application, with very
little typing required anymore, and with more kinds of displays
available.  Cygnus customers have been very enthusiastic about this
one.

This is a Cygnus project rather than an FSF project, RMS having
forbidden the inclusion of tcl/tk-based GUIs in FSF releases of GDB.
At the moment, we're only planning to release the source code in
snapshot form, pending a decision about how to make it available via
CVS (with the rest of GDB, or from a separate repository).  The GUI
code is GPLed, copyright Cygnus.

Eventually we expect to make releases also.  We'll most likely follow
the same practice as we did for the releases of GDBtk 4.15 and 4.16;
GDB + GUI releases available by ftp from Cygnus, with official FSF
releases being GUI-less as usual.

We're still working out all the details, and expect to make an
announcement to the general public soon.  Since we would like people
to contribute to Insight, just as with GDB, I would like to hear from
you about what you want, in particular what will help you develop and
use Insight - more internals docs, more screenshots, more deprecation
of tix :-), CVS write access, recoding into Guile :-) :-), etc.

								Stan

Re: breakpoint extension for remote protocol, take II

[Jim Blandy]

> I'd like to seriously propose that:
> 
> 	[qQ][A-Z].*
> 
> be reserved for GDB's internal use while:
> 
> 	[qQ][a-z].*
> 
> be declared as available for custom jobs.

I guess I don't understand the distinction between "GDB's internal
use" and "custom jobs."  The interpretation that comes to mind first
is work that will go into the standard GDB distribution vs. stuff that
won't.  That doesn't seem predictable.

Re: breakpoint extension for remote protocol, take II

[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
From shebs@cygnus.com Mon Jun 14 16:51:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Testsuite Organization Proposal
Date: Mon, 14 Jun 1999 16:51:00 -0000
Message-id: <199906142351.QAA06182@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00162.html
Content-length: 1701

I'd like to propose a semi-formalization of the current testsuite
organization, basically just reflecting current practice, but with
enough precision to guide further additions.  The testsuite is key for
GDB developers; the breadth of functionality and platforms is now so
broad, in many cases, users won't discover regressions for months or
years after the change that caused them; while a testsuite run often
reveals mistakes right away.

First of all, testsuite organization mainly serves the purpose of
intelligibility; DejaGNU finds all the expect scripts wherever they're
placed.  But with around 6000 tests in all, it becomes important to
organize them sensibly.

gdb.base	This is the base testsuite.  The tests in it should
		apply to all configurations of GDB (but generic
		native-only tests may live here).  The test programs
		should be in a subset of C that is valid K&R, ANSI/ISO,
		and C++ (ifdefs are allowed).

gdb.<lang>	Language-specific tests for all languages besides C.

gdb.<platform>	Non-portable tests.  The tests are specific to a specific
		configuration (host or target), such as HP-UX or eCos.

gdb.<compiler>	Tests specific to a particular compiler.  There aren't
		currently any groups of tests in this category that
		couldn't just as sensibly be made platform-specific,
		but one could imagine a gdb.gcc, for tests of GDB's
		handling of GCC extensions.

gdb.<subsystem>	Tests that exercise a specific subsystem in more depth.
		For instance, gdb.disasm exercises various disassemblers,
		while gdb.stabs tests pathways through the stabs reader.

Please feel free to comment on this.  If everybody thinks this is great,
I'll add to the internals manual.

								Stan
From shebs@cygnus.com Mon Jun 14 16:59:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: breakpoint extension for remote protocol, take II
Date: Mon, 14 Jun 1999 16:59:00 -0000
Message-id: <199906142359.QAA06291@andros.cygnus.com>
References: <5mwvx62vl7.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q2/msg00163.html
Content-length: 777

   Date: 14 Jun 1999 16:47:32 -0700
   Lines: 39

   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.

You mean like with qOffsets, that's been standardly issued by GDB for
years? :-)

Actually, I don't ever remember hearing that 'q' was supposed to be
experimental, and the existing docs don't seem to say so either.  At
this point we would have to pick a different char I think, and be very
disciplined about not allowing any usages of it into the standard
sources, so that it really can be for experimentation.

In general, we have a sizeable documentation gap with the remote
protocol; it's become so ubiquitous it ought to have its own RFC... :-)

								Stan

breakpoint extension for remote protocol, take II

[J.T. Conklin]

I've had some time to refine my break/watchpoint extensions, and have
come up with this revised proposal.

	Request		Packet

	insert break	B<type>,<address>[,<length>]

	reply		OK	for success.
			ENN	for an error.

	
	remove break	D<type>,<address>[,<length>]

	reply		OK	for success.
			ENN	for an error.

In my earlier proposal, if the 'B' command successfully inserted a
breakpoint, it returned a integer cookie uniquely identifying that
breakpoint.  The 'D' command used the cookies to remove breakpoints.
I have changed 'D' to specify breakpoints in the same manner as they
are inserted.  

This was done because GDB internally represents break/watchpoints by
type/address/length. It would require additional hair in both GDB's
remote.c and the stub to index breakpoints by a cookie.  In light of
this, there is no compelling reason to use a cookie.

I also proposed using the characters 'r', 'w', and 'x' for <type>
(indicating read, write and execute breakpoints), but I now think
<type> should be an integer.  I found that there are at least 5 types
that need to be supported.  And although I can't think of any more off
hand, there may be more.  A numeric <type> is a bit easier to parse in
the stub, and although the 'r', 'w', 'x' mnemonic is nice, it's likely
to break down as new types are added.  Since the remote protocol is
primarily for machine/machine communication, an integer is sufficient.

There was one type defined for execution breakpoints, but I've decided
that separate types to indicate software and hardware breakpoints are
required.  It's unrealistic to assume that the stub can make the
decision whether to use a hard- or soft- breakpoint as well as the
programmer driving GDB.  I've also discovered that GDB currently
supports read, write, and read/write (access) watchpoints.

My current definition for <type> is:
	0	software breakpoint
	1	hardware breakpoint
	2	write watchpoint
	3	read watchpoint
	4	read/write (access) watchpoint

It so happens that the <type>s used for watchpoints are the same as the 
the TYPE argument to target_{insert,remove}_watchpoint + 2.


Thoughts?  I'd like to get the protocol nailed down so I don't have to
change it after I roll it out within RedBack.

	--jtc

-- 
J.T. Conklin
RedBack Networks