From: Bill Gatliff <gatliff@haulpak.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Fri, 03 Dec 1999 05:41:00 -0000 [thread overview]
Message-ID: <3847C872.55287A40@haulpak.com> (raw)
In-Reply-To: <38470CC1.1B0E5C27@ozemail.com.au>
Steven:
[snip snip]
Sounds like we agree more than we disagree. *whew*! :^)
> Yes, here's the issue. The document is completely lacking in stub
> implementation guidelines. IMHO, there needs to be a section of the
> protocol (or comments throughout it) that give this sort of information
> and advice to implementers of stubs.
Here's where a good reference stub library might be of use. (As instructive as
they are, I'm not sure the example stubs qualify in this department).
I'm working on such a beast, mostly because I routinely work with more than one
type of embedded processor. I have it done for the SH-2 (although I'm still
adding some exception handling), someone is helping with an ARM port, and Dave
Williams is looking at for a 68k port.
If anyone else was interested in the code, I would be happy to see it placed on a
Cygnus web/cvs site somewhere--- at the moment, however, I don't have the
resources or time to set something up myself.
> Again I agree with this. I was making the observation that Character
> Escaping is likely to become more prevalent as the protocol evolves. To
> define character escaping around one message could create a situation
> where different messages that require it implement different mechanisms.
Escaping seems to be most needed in messages with binary content, of which there
are few. Hopefully this will continue to be the case, but since programs are
getting bigger all the time, X and similar messages may become a necessity...
:^( In that situation, standardized escaping would be a real bonus.
> What would probably be more appropriate is to state how escaping is
> performed where required as part of the base level protocol. Then in the
> message put a statement like, "This message contains binary data and
> must be Escaped using the standard escaping mechanism defined above".
Right. If you've got to do it, at least make it consistent.
> 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.
Agreed. Maybe RLE and escaping go at the level that $#+- are at, instead of on a
per-message basis, so the protocol will allow you to RLE or escape *any*
message. I think that's what you're saying, anyway...
> 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
Or maybe a new kind of query? I'm not sure I like that approach, but queries may
have been created with stuff like this in mind. With only slightly more than a
year of gdb under my belt, however, I don't have enough experience to say.
Perhaps someone else does?
b.g.
--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems
next prev parent reply other threads:[~1999-12-03 5:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199911090706.CAA13120@zwingli.cygnus.com>
[not found] ` <199911102246.RAA01846@mescaline.gnu.org>
[not found] ` <npr9hi321d.fsf@zwingli.cygnus.com>
[not found] ` <199911231303.IAA01523@mescaline.gnu.org>
[not found] ` <npr9hg2a9t.fsf@zwingli.cygnus.com>
[not found] ` <199911251715.MAA09225@mescaline.gnu.org>
1999-11-30 10:20 ` none Jim Blandy
1999-12-01 0:21 ` ST(i) and MMj Eli Zaretskii
[not found] ` <npogca9tb8.fsf@zwingli.cygnus.com>
[not found] ` <3845AB0E.3795D99E@ozemail.com.au>
1999-12-01 15:43 ` Standard GDB Remote Protocol Quality Quorum
1999-12-01 15:53 ` Stan Shebs
[not found] ` <5md7sql00o.fsf@jtc.redbacknetworks.com>
[not found] ` <3845F45A.38EA29CF@ozemail.com.au>
[not found] ` <384685A7.15184EB1@haulpak.com>
[not found] ` <38470CC1.1B0E5C27@ozemail.com.au>
1999-12-03 5:41 ` Bill Gatliff [this message]
1999-12-07 14:13 ` J.T. Conklin
[not found] ` <38478987.EECEEBF@cygnus.com>
[not found] ` <199912061134.GAA16617@mescaline.gnu.org>
[not found] ` <npk8msaqoo.fsf@zwingli.cygnus.com>
1999-12-08 1:46 ` ST(i) and MMj Eli Zaretskii
[not found] ` <npogc1afwn.fsf@zwingli.cygnus.com>
[not found] ` <199912091029.FAA13387@mescaline.gnu.org>
1999-12-10 5:51 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3847C872.55287A40@haulpak.com \
--to=gatliff@haulpak.com \
--cc=gdb@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox