From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Steven Johnson Cc: gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Tue, 07 Dec 1999 14:13:00 -0000 Message-id: <5mn1rmz9g8.fsf@jtc.redbacknetworks.com> References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> <199912010821.DAA27130@mescaline.gnu.org> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> X-SW-Source: 1999-q4/msg00466.html >>>>> "Steven" == Steven Johnson writes: >> Since you're putting up your hand, would you be willing to review the >> protocol spec and point out areas that are ambiguous, confusing, need >> revising, etc? Steven> Following is a Hopefully Constructive Critique, of the GDB Remote Steven> Protocol. Many thanks. I realize I'm late in this response, but I read your message as soon as it came in. I was quite pleased that you found so many issues so quickly. Steven> Packet Structure: Steven> Simple structure, obviously originally designed to be able to be driven Steven> manually from a TTY. (Hence it's ASCII nature.) However, the protocol Steven> has evolved quite significantly and I doubt it could still be used very Steven> efficiently from a TTY. That said, it still demarks frames effectively. I'm a bit more pessimistic. I believe that framing was effective in the original protocol (although I would have put the checksum inside the packet delimeters); but recent changes have muddied the distinc- tion between the debug protocol and the data link layer to the point where they are now inseparable. I think this is most unfortunate. Steven> Sequence Numbers: Steven> Definition of Sequence ID's needs work. Are they necessary? Are they Steven> deprecated? What purpose do they currently serve within GDB? One would Steven> imagine that they are used to allow GDB to handle retransmits from a Steven> remote system. Reading between the lines, this is done to allow error Steven> recovery when a transmission from target to host fails. Possible Steven> sequence being: I'm sure that you understand that we have to document the protocol as it is, rather than how we would like it to be. The protocol allows a good deal of flexibility in adding new commands, which GDB can use by probing the remote stub. This allows the protocol to evolve without requiring all existing stubs to be changed. Unfortunately, there is not a similar ability to change the data-link layer. The cases where we've done so (RLE, binary write) have had unfortunate consequences that were not realized until too late. That's a long and roundabout way of saying that sequence numbers have limited usefulness, and it will be difficult if not impossible to fix them. All a stub does is append the sequence number to the ack. GDB could use this to ensure that it's not misinterpreting the ACK for another packet or a '+' found within a packet, but it can't assume that stubs will reject subsequent packets with the same sequence number (duplic- ate packets). Another problem, not with the spec but with the implementation is that naks to packets with sequence numbers should also append the sequence number, but none of the sample stubs do this. Steven> <- $packet-data#checksum Steven> -> + Steven> -> $sequence-id:packet-data#checksum (checksum fails or receive timeout Steven> halfway through packet). Steven> <- -sequence-id Steven> -> $sequence-id:packet-data#checksum Steven> <- +sequence-id Steven> When do the sequence-id's increment? Presumably on the successful Steven> receipt of the +sequence-id acknowledgement. Steven> If they increment on the successful acknowledgement, what happens if the Steven> acknowledgement is in error? For example a framing error on the '+'. The Steven> target would never see the successful acknowledgement and would not Steven> increment it's sequence number. Steven> So what if it doesn't? The +/- Ack/Nak mechanism should be amply Steven> sufficient to allow retransmits of missed responses. Steven> I can see little practical benefit in a sequence-id in the responses, as Steven> it is currently documented. This is supported buy the comment within the Steven> document: "Beyond that its meaning is poorly defined. GDB is not known Steven> to output sequence-ids". This tends to indicate that the mechanism has Steven> fallen out of use, Probably because it doesn't actually achieve Steven> anything. If this is the case, it could be deprecated. However, I would Steven> advocate not deprecating it from the protocol, because If they were sent Steven> by GDB a current hole I believe is in the protocol could be plugged. (I Steven> will discuss this hole later in this critique.) Steven> Ack/Nak Mechanism: Steven> Simple Ack/Nak Mechanism, using + and - Respectively. Also Steven> reflects the simple ASCII basis of the protocol. My main Steven> concern with this system is there is no documentation of Steven> timing. Usually Ack/Nak must be received within a certain time Steven> frame, otherwise a Nak is assumed and a retransmit Steven> proceeds. This is necessary, because it is possible for the Steven> Ack/Nak character to be lost (however unlikely) on the line Steven> due to a data error. I think there should be a general timing Steven> basis to the entire protocol to tie up some potential Steven> communications/implementation problems. Yes, the protocol should talk about timeouts. IMHO the timeouts need to be presented as variables rather than absolutes, as the acceptable timeout will vary greatly depending on situation. There is GDB variable 'remotetimeout' which is used for timeouts, but there are more than one timeout should distinguish even if GDB and the stubs do not. Two that come to mind are the time between a packet is sent and an ack/nak is sent in response, and the time between a ack'd command is sent and a response is received. Steven> Once the $ character for the start of a packet is transmitted, each Steven> subsequent byte must be received within "n" byte transmission times. Steven> (This would allow for varying comms line speeds). Or alternately a Steven> global timeout on the whole message could be define one "$" (start Steven> sentinel) is sent, the complete message must be received within "X" Steven> time. I personally favour the inter character time as opposed to Steven> complete message time as it will work with any size message, As above, rather than come up with a heuristic like n * bit rate, or n ticks (in whatever unit) per packet, I believe that GDB must provide a variable (or variables) for timeouts. For example, both of the above would fail with a high latency connection, perhaps commands to a mars probe... Steven> One possible timeout that would be easy to work with could be: Steven> Timeout occurs 1 second after the last received byte. This might lose for very low bandwidth connections, perhaps commands to submerged submarines. Steven> For ACK/NAK I propose that something needs to be defined along Steven> the lines: ACK/NAK must be received within X Seconds from Steven> transmission of the end of the message, otherwise a NAK must Steven> be assumed. Steven> There is no documentation of the recovery procedure, Does GDB Steven> retransmit if its message is responded to with a NAK? If not, Steven> what does it do? How is the target supposed to identify and Steven> handle retransmits from GDB. GDB retransmits commands 3 times and gives up. This is a hardcoded constant --- there is no 'remoteretries' variable. Steven> What happens if something other than + or - is received when Steven> ACK/NAK is expected. (For example $). A '$' is assumed to be an old response. It then calls getpkt() to eat up the packet. Even if it is a packet, getpkt() is probably going to fail because the '$' has already been read. Any other character is considered to be junk and is discarded. There is no timeout so if the stub continuously spews junk, the connection will hang. Steven> If this is the intent of sequence-id and it has fallen into Steven> disuse, then to allow it's re-introduction at a later date, it Steven> could be documented that if GDB sends a sequence-id, then the Steven> retransmit processing I've documented here operates, otherwise Steven> the currently defined behaviour operates, and that sequence-id Steven> is only sent by the target in responses where they are present Steven> in the original GDB message. This would allow GDB to probe if Steven> the target supports secure and recoverable message delivery or Steven> not. I'm a bit fuzzy here. It's not clear how GDB can probe whether the stub supports a reliable transport, since there are so many stubs in the field that respond with an ack with an appended sequence number after receiving a packet with a sequence number. Steven> Run Length Encoding: Steven> Is run length encoding supported in all packets, or just some packets? Steven> (For example, not binary packets) It's supported on all packets from the target to GDB. It's unfortunate that this isn't symetric, because it would be most useful in one of the most issued commands: write all registers. Steven> Why not allow lengths greater than 126? Or does this mean lengths Steven> greater than 97 (as in 126-29) The run length is encoded as a printable ASCII value, so the run length should not be greater than 97. Steven> If binary packets with 8 bit data can be sent, why not allow Steven> RLE to use length also greater than 97. If the length maximum Steven> is really 126, then this yields the character 0x9B which is 8 Steven> bits, wouldn't the maximum length in this case be 226. Or is Steven> this a misprint? Packets with 8 bit values are still problematic. Even the probe GDB does to determine whether the binary memory write command exists is no guarentee that all possible values can be transmitted. Steven> Why are there 2 methods of RLE? Is it important for a Remote Steven> Target to understand and process both, or is the "cisco Steven> encoding" a proprietary extension of the GDB Remote protocol, Steven> and not part of the standard implementation. The documentation Steven> of "cisco encoding" is confusing and seems to conflict with Steven> standard RLE encoding. They appear to be mutually Steven> exclusive. If they are both part of the protocol, how are they Steven> distinguished when used? Some companies have made their own modifications to the remote protocol without consulting or working with the GDB maintainers. In some cases, they later decide to contribute their extensions. This is the case of the Cisco remote protocol extensions. GDB distinguishes the remote protocol and the Cisco varient by treating them as separate protocols that happen to share a lot of code. I still think the integration of Cisco's changes were not in the best interest of GDB. But one thing I think they did right was their implementation of RLE. At the expense of one extra character to express the run length, 256 bytes can be represented. Steven> Deprecated Messages: Steven> Should an implementation of the protocol implement the deprecated Steven> messages or not? What is the significance of the deprecated messages Steven> to the current implementation? I think not. Commands have been depricated because: * they were insufficently specified * were never implemented in a released GDB and/or sample debug stubs * were replaced by a better way of doing things. * etc. In the table of comands, I'd prefer that instead of some commands be marked 'optional', that the required commands (g/G/m/M/c) be marked required. Steven> Character Escaping: Steven> The mechanism of Escaping the characters is not Steven> defined. Further it is only defined as used by write mem Steven> binary. Wouldn't it be useful for future expansion of the Steven> protocol to define Character Escaping as a global feature of Steven> the protocol, so that if any control characters were required Steven> to be sent, they could be escaped in a consistent manner Steven> across all messages. Also, wouldn't the full list of escape Steven> characters be $,#,+,-,*,0x7d. Otherwise, + & - might be Steven> processed inadvertently as ACK or NAK. If this can't happen, Steven> then why must they be avoided in RLE? If they are escaped Steven> across all messages, then that means they could be used in RLE Steven> and not treated specially. IMO the problem with character stuffing is that it's happining at the protocol layer instead of the data link layer. You're right that the full list of characters should include '$', '#', '+', and '-'. Although GDB -> target RLE is not performed, '*' should be probably done done in case it is (or binary memory read) is implemented. In addition, I'd include characters with values 0-31 and 128-159 to avoid problems with serial links that don't handle control characters. Perhaps with some sort of data link negotiation that would open up larger windows. Another benefit with doing character stuffing at the data link layer is that it avoids dealing with variable length packets at the protocol layer. But I don't know how we could fix this now. Steven> 8/7 Bit protocol. Steven> With the documentation of RAW Binary transfers, the protocol moves from Steven> being a strictly 7 bit affair into being a 8 bit capable protocol. If Steven> this is so, then shouldn't all the restrictions that are placed from the Steven> 7 bit protocol days be lifted to take advantage of the capabilities of Steven> an 8 bit message stream. (RLE limitations, for example). Would anyone Steven> seriously be using a computer that had a 7 bit limitation anymore Steven> anyway? (At least a computer that would run GDB with remote debugging). I'm more concerned with the other side than the GDB side. I can imagine a target that could only reasonably support a 7 bit channel. Steven> Thoughts on consistency and future growth: Steven> Apply RLE as a feature of All messages. (Including binary messages, as Steven> these can probably benefit significantly from it). Steven> Apply the Binary Escaping mechanism as a feature of the packet that is Steven> performed on all messages prior to transmission and immediately after Steven> reception. Define an exhaustive set of "Characters to be escaped". Steven> Introduce message timing constraints. Steven> Properly define sequence-id and allow it to be used from GDB to make Steven> communications secure and reliable. These are all great, but I'm not sure how much can been within the confines of the existing protocol. --jtc -- J.T. Conklin RedBack Networks >From jtc@redback.com Tue Dec 07 14:53:00 1999 From: jtc@redback.com (J.T. Conklin) To: Bill Gatliff Cc: gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Tue, 07 Dec 1999 14:53:00 -0000 Message-id: <5miu2az7lb.fsf@jtc.redbacknetworks.com> References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> <199912010821.DAA27130@mescaline.gnu.org> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com> <38470CC1.1B0E5C27@ozemail.com.au> <3847C872.55287A40@haulpak.com> X-SW-Source: 1999-q4/msg00467.html Content-length: 2355 >>>>> "Bill" == Bill Gatliff writes: >> This way if you don't implement any of those messages, you don't need to >> implement Escaping. But it advantageous in that it defines how escaping >> will be used in any/all messages that require it. I think the same >> should be said for RLE. Bill> Agreed. Maybe RLE and escaping go at the level that $#+- are at, Bill> instead of on a per-message basis, so the protocol will allow you Bill> to RLE or escape *any* message. I think that's what you're saying, Bill> anyway... Had binary data been quoted at the data link layer, the implementation would have been a lot simpler and likely more robust. I wish I would have noticed this back when I objected to binary write being added as 4.18 was being released. Unfortunately, I can't see how we can do this in a compatible manner. The character stuffing increases the packet length. The memory write command compensates by reducing the length of the data being written, resulting in a packet < PBUFSIZ. Ideally you don't want the protocol layer to know these kind of details --- only the link layer MTU. This would work fine if both GDB and the stub did quoting at the link layer. Gdb could send a packet that, after stuffing, was larger than PBUFSIZ. But this would not be a problem because the new stub would un-stuff (and un-rle) packets as they are received. But if such a GDB was communicating to a stub that didn't unstuff until the 'X' command was processed, packet buffers may overflow. >> Maybe each message needs a check list that >> states what features it may use like this: >> >> My new Message U My comments on this message Bill> Or maybe a new kind of query? I'm not sure I like that Bill> approach, but queries may have been created with stuff like this Bill> in mind. With only slightly more than a year of gdb under my Bill> belt, however, I don't have enough experience to say. Perhaps Bill> someone else does? Perhaps we could have a query command used determine data link layer capabilities. It would have to be issued at the initial connection, and would have to be issued with the least-common-denominator 7 bit query, no-rle, framing. It's a bit ugly... I don't like it... but it probably could be made to work. --jtc -- J.T. Conklin RedBack Networks >From jimb@cygnus.com Tue Dec 07 15:07:00 1999 From: Jim Blandy To: gdb@sourceware.cygnus.com Subject: i386 info float Date: Tue, 07 Dec 1999 15:07:00 -0000 Message-id: <199912072307.SAA02179@zwingli.cygnus.com> X-SW-Source: 1999-q4/msg00468.html Content-length: 1367 We were notified yesterday that the FSF had received the copyright papers for Mark's `info float' command, so it's in the sources now. It should appear in the next snapshot. Thanks very much, Mark! Persons of proper upbringing will be shocked to learn that there are no less than eight distinct implementations of `info float' for the x86. Now, the Sequent machines do have the Weitek FPU, so one could plausibly argue that they merit their own `info float' command. But they don't. (As far as I can tell.) So the duplication is completely gratuitous. They are as follows: The one we want to keep: i387-tdep.c:i387_float_info Maintained platforms: go32-nat.c:i386_go32_float_info (Eli's bailiwick) i386gnu-nat.c:i386_mach3_float_info (Mark's bailiwick) i386b-nat.c:i386_float_info (used on all BSD's; any takers?) i386v-nat.c:i386_float_info (#if 0'd out) Unmaintained platforms (as far as I know): i386m3-nat.c:i386_mach3_float_info (unmaintained) i386aix-nat.c:i386_float_info (unmaintained) symm-nat.c:i386_float_info (unmaintained) I'm going to delete the definition from i386v-nat.c. As far as I know, there are no BSD GDB folks participating in this list, so we'll just have to wait until someone speaks up about them. So, once Eli and Mark have taken care of their targets, we're basically done. >From jtc@redback.com Tue Dec 07 15:33:00 1999 From: jtc@redback.com (J.T. Conklin) To: William Gatliff Cc: gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Tue, 07 Dec 1999 15:33:00 -0000 Message-id: <5md7siz5qb.fsf@jtc.redbacknetworks.com> References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> <199912010821.DAA27130@mescaline.gnu.org> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com> X-SW-Source: 1999-q4/msg00469.html Content-length: 2083 >>>>> "William" == William Gatliff writes: William> If efficiency/throughput is a problem, then go to ethernet. William> At 10/100Mbps, even the overhead of ASCII isn't a problem for William> most targets I can think of. Yet the protocol should be as efficent as possible. For many targets, ethernet and a TCP/IP stack is a heavyweight requirement. I looked at cleanly separating the layers in remote.c so I could use UDP some time ago. About the same time, the mini-telnet stuff came in which assumes a stream transport. Bleh. Steven> I think there should be a general timing basis to the entire Steven> protocol to tie up some potential communications/ Steven> implementation problems. William> The RSP's lack of timing requirements is an asset, as far as I'm William> concerned. See below. Although Steven mentioned several alternatives of computing timeout values from bit rate, message size, etc.; I believe that those are secondary to his point that the protocol should identify that time- outs are necessary to guarantee a reliable. Once they are identified, the lengths of those timeouts can be implemented by GDB variables or manifest constants in stub code, etc. But without them, I think that we'll continue to have weaknesses in both. Steven> Character Escaping: The mechanism of Escaping the characters is not Steven> defined. Further it is only defined as used by write mem binary. William> That's because this is the only place where it is needed, William> AFAIK. It's the only place where it's used now. But I wouldn't go so far as saying that it's the only place where it's needed. Perhaps even more useful than binary memory write is binary register write. Registers are written quite often while stepping through a program. Likewise, it would be useful to have a binary memory read and binary register read. IMO, using the same escaping mechanisms for all such commands would be good thing. To do so, I'd put it at the data link layer instead of inside each command. --jtc -- J.T. Conklin RedBack Networks >From jtc@redback.com Tue Dec 07 15:49:00 1999 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: Steven Johnson , gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Tue, 07 Dec 1999 15:49:00 -0000 Message-id: <5m9036z518.fsf@jtc.redbacknetworks.com> References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> <38478423.6ACE7BF8@cygnus.com> X-SW-Source: 1999-q4/msg00470.html Content-length: 1301 >>>>> "Andrew" == Andrew Cagney writes: Andrew> How GDB behaves should be clarified. However, any definition should Andrew> avoid refering to absolute times and instead refer the user back to a Andrew> number of knobs that can be tweeked from the GDB command line. Steven is/was examining the protocol specification without the GDB and stub sources to avoid becoming biased by exposure. In addition, I recommend that, at least at the present time, this also be true of GDB's variables. If Steven is willing to carry this a bit farther, I'd like to see the protocol defined in terms of 'variables' which can be later mapped to GDB's variables. Or in the case where GDB does not have such a user configurable varible, a concious decision can be made whether to add one or continue using whatever constant is in the source. For example, this thread has me thinking that there are actually two separate timeouts in the protocol. The timeout from when a packet is sent and it is ACK/NAKed. And a timeout from when a command is sent and it's response is received. At the present time, 'remotetimeout' is used for both purposes. But it's reasonable to set the first to a short value and the latter to something much larger. --jtc -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Tue Dec 07 16:08:00 1999 From: Andrew Cagney To: jtc@redback.com Cc: pschen@puma.cs.nthu.edu.tw, gdb@sourceware.cygnus.com Subject: Re: Exist a 68k simulator? Date: Tue, 07 Dec 1999 16:08:00 -0000 Message-id: <384DA0FF.86D558DF@cygnus.com> References: <5mwvqqzh1s.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00471.html Content-length: 376 "J.T. Conklin" wrote: > > Where can I find a 68k simulator? ( want to put in /sim directory) > > Isn't there 68k simulator used in the PalmPilot and that coin-op video > game emulator? Do the licences for those allow for inclusion within > GDB? No one is exactly clear on that one. If the answer had been yes, it would have been integrated long ago :-) enjoy, Andrew >From jsm@cygnus.com Tue Dec 07 16:17:00 1999 From: Jason Molenda To: Andrew Cagney Cc: jtc@redback.com, pschen@puma.cs.nthu.edu.tw, gdb@sourceware.cygnus.com Subject: Re: Exist a 68k simulator? Date: Tue, 07 Dec 1999 16:17:00 -0000 Message-id: <19991207161726.B20332@cygnus.com> References: <5mwvqqzh1s.fsf@jtc.redbacknetworks.com> <384DA0FF.86D558DF@cygnus.com> X-SW-Source: 1999-q4/msg00472.html Content-length: 1056 On Wed, Dec 08, 1999 at 11:06:23AM +1100, Andrew Cagney wrote: > "J.T. Conklin" wrote: > > > > Where can I find a 68k simulator? ( want to put in /sim directory) > > > > Isn't there 68k simulator used in the PalmPilot and that coin-op video > > game emulator? Do the licences for those allow for inclusion within > > GDB? > > No one is exactly clear on that one. If the answer had been yes, it > would have been integrated long ago :-) I'll repeat the plug for the Unix Amiga Emulator projects' 68000/68020/68881 simulator. http://www.freiburg.linux.de/~uae/ I talked to the author/maintainer, Bernd Schmidt, about using it in GDB a while ago. He expect no problems. It is GPL'ed. It is not the most complete 68k simulator in the world, but he expected that it would handle gcc-generated code OK. It has been appropriated by several other projects as a generic CPU simulator in the past. I don't have time to pursue this any further right now, but that looks like a very good avenue to pursue if someone wanted to pull in a 68k simulator. J >From ac131313@cygnus.com Tue Dec 07 16:32:00 1999 From: Andrew Cagney To: jtc@redback.com Cc: Steven Johnson , gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Tue, 07 Dec 1999 16:32:00 -0000 Message-id: <384DA6B9.339ED90D@cygnus.com> References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> X-SW-Source: 1999-q4/msg00473.html Content-length: 1464 "J.T. Conklin" wrote: > > >>>>> "Andrew" == Andrew Cagney writes: > Andrew> How GDB behaves should be clarified. However, any definition should > Andrew> avoid refering to absolute times and instead refer the user back to a > Andrew> number of knobs that can be tweeked from the GDB command line. > > Steven is/was examining the protocol specification without the GDB > and stub sources to avoid becoming biased by exposure. In addition, > I recommend that, at least at the present time, this also be true of > GDB's variables. > > If Steven is willing to carry this a bit farther, I'd like to see the > protocol defined in terms of 'variables' which can be later mapped to > GDB's variables. Or in the case where GDB does not have such a user > configurable varible, a concious decision can be made whether to add > one or continue using whatever constant is in the source. That would be bliss. > For example, this thread has me thinking that there are actually two > separate timeouts in the protocol. The timeout from when a packet is > sent and it is ACK/NAKed. And a timeout from when a command is sent > and it's response is received. At the present time, 'remotetimeout' > is used for both purposes. But it's reasonable to set the first to a > short value and the latter to something much larger. There is also (as noted earlier) the time between each character that arrives. GDB uses the same timeout for that. Andrew >From ac131313@cygnus.com Tue Dec 07 17:03:00 1999 From: Andrew Cagney To: jtc@redback.com Cc: Steven Johnson , gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Tue, 07 Dec 1999 17:03:00 -0000 Message-id: <384DAE26.241BCE2B@cygnus.com> References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> X-SW-Source: 1999-q4/msg00474.html Content-length: 2366 "J.T. Conklin" wrote: > > Steven> 8/7 Bit protocol. > Steven> With the documentation of RAW Binary transfers, the protocol moves from > Steven> being a strictly 7 bit affair into being a 8 bit capable protocol. If > Steven> this is so, then shouldn't all the restrictions that are placed from the > Steven> 7 bit protocol days be lifted to take advantage of the capabilities of > Steven> an 8 bit message stream. (RLE limitations, for example). Would anyone > Steven> seriously be using a computer that had a 7 bit limitation anymore > Steven> anyway? (At least a computer that would run GDB with remote debugging). > > I'm more concerned with the other side than the GDB side. I can > imagine a target that could only reasonably support a 7 bit channel. Yes, it's optional for that reason (and yes, the spec should clarify that :-) > Steven> Thoughts on consistency and future growth: > Steven> Apply RLE as a feature of All messages. (Including binary messages, as > Steven> these can probably benefit significantly from it). > > Steven> Apply the Binary Escaping mechanism as a feature of the packet that is > Steven> performed on all messages prior to transmission and immediately after > Steven> reception. Define an exhaustive set of "Characters to be escaped". > > Steven> Introduce message timing constraints. > Steven> Properly define sequence-id and allow it to be used from GDB to make > Steven> communications secure and reliable. > > These are all great, but I'm not sure how much can been within the > confines of the existing protocol. As a vague suggestion of a ``five year'' gdb-protocol plan: v2.0: Formalize the lower layers (transport, ...?) (Where's my AST networks book :-) and address issues such as reliability. The command set would remain the same - warts and all. v3.0: Look at the actual gdb command set If the two can be separated then, there is some hope of being able to move forward. As an incentive, the getpkt() and putpkt() functions and several chunks of remote.c need a further rewrite any way. They should to be inverted so that they are based on an event model. Clearly separating the layers would help this. The alternative, as always, is to start again from scratch. Andrew (As for the mini-telnet, if someone would like to propose a decent telnet extenstion to the protocol then, I'm all ears) >From shebs@cygnus.com Tue Dec 07 17:41:00 1999 From: Stan Shebs To: jsm@cygnus.com Cc: cagney@cygnus.com, jtc@redback.com, pschen@puma.cs.nthu.edu.tw, gdb@sourceware.cygnus.com Subject: Re: Exist a 68k simulator? Date: Tue, 07 Dec 1999 17:41:00 -0000 Message-id: <199912080138.RAA27224@andros.cygnus.com> References: <19991207161726.B20332@cygnus.com> X-SW-Source: 1999-q4/msg00475.html Content-length: 962 Date: Tue, 7 Dec 1999 16:17:26 -0800 From: Jason Molenda I'll repeat the plug for the Unix Amiga Emulator projects' 68000/68020/68881 simulator. http://www.freiburg.linux.de/~uae/ I talked to the author/maintainer, Bernd Schmidt, about using it in GDB a while ago. He expect no problems. It is GPL'ed. It is not the most complete 68k simulator in the world, but he expected that it would handle gcc-generated code OK. It has been appropriated by several other projects as a generic CPU simulator in the past. I don't have time to pursue this any further right now, but that looks like a very good avenue to pursue if someone wanted to pull in a 68k simulator. Indeed, this would be a good project for someone that wanted to get their feet wet in embedded GDB hacking. The technical parts are not too hard, you don't need special hardware, and people will appreciate the contribution. Stan