Re: breakpoint extension for remote protocol, take II

[Jim Blandy <jimb@cygnus.com>]

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