From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: breakpoint extension for remote protocol, take II Date: Wed, 16 Jun 1999 14:06:00 -0000 Message-id: References: <199906142359.QAA06291@andros.cygnus.com> <3765A855.5EF176AF@cygnus.com> X-SW-Source: 1999-q2/msg00176.html > > 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 To: Jim Blandy 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> 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: { } (``!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 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= and i 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 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 -> output-from-command (Well another posibility would be ``QScript=''.) 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 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 -> { } ::= All prefix letters and strings reconized by the monitor vis: S qCRC qL qP qC ::= 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 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