This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Standard GDB Remote Protocol


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]