This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: protoc spec
- To: qqi at world dot std dot com
- Subject: Re: protoc spec
- From: Stan Shebs <shebs at cygnus dot com>
- Date: Thu, 16 Dec 1999 13:54:17 -0800
- CC: gdb at sourceware dot cygnus dot com
Date: Thu, 16 Dec 1999 00:45:28 -0500 (EST)
From: Quality Quorum <qqi@world.std.com>
I have updated GDB remote protocol specs with a few things which are
making it possible to do real develpment on its base. Latest spec
is attached to this mail, also I put it on the net:
Thanks for working on this!
My inclination for the ultimate disposition of this spec is to enhance
the protocol's description in the main GDB manual. That is the only
GDB documentation that users (including stub developers) normally see,
and it already has a lengthy description of the protocol. So if there
is another specification somewhere, then we'll have to spend the rest
of our lives keeping the two in sync. One might argue that the user
manual should have a more informal description, but since it's aimed
at stub developers, who need the most accurate info, I don't see much
value in a second written description.
1. It seems possible to fix all issues I was concerned about
in such a way that properly developed application will
be backward comaptible without any additonal efforts.
And all quirks could be covered by just three configuration
variables on the gdb side.
Although I generally tend to favor user-settable variables, I'm not
so keen to make users have to set them in order to keep things working
correctly. "If it ain't broken, don't fix it."
I am very eager to submit appropriate remote.c and I already
signed copyright transfer papers.
Instead of submitting an entire new remote.c, you should break changes
down into specific patches and submit each separately.
Also, after 7 years of heavy involvment with network protocol
development I am kind of attached to internet-drafts and RFCs.
Does it seem as a good idea to publish final spec as RFC ?
It seems to me that applicaton management area of IETF
would provide a very good review at least. At the same time
it introduces noticeable delays into process. So, I am not
quite sure.
Hmmm, novel idea. This protocol is not really an "Internet protocol",
it's more like a private protocol used by programmers during the
development process. How large is a "noticeable delay"? If it's
too large, then it could interfere with GDB development.
2. Remote GDB Stub Execution Environment
Let us start from describing environment where remote stub is executed.
It is generally assumed that stub is executed in exception handling
context with all other processes in the system under debugging
(the system) frozen until stub receives command from gdb to continue.
Even if the stub supports per thread breakpoints, all threads of
execution in the system are frozen when breakpoint/exception
is taken by any one of them
This is a little too restricted in its scope. There are at least six
basic models of stub usage, some involving interesting combinations of
simulators and hardware boxes, and then there's the gdbserver replay
feature. That's really why we rely on the protocol spec; as long as
the stub conforms to the spec, GDB will just assume that it's providing
a meaningful view of the actual target environment.
Note: this specification required low case encoding. It is generally
established practice so there are no compatibility problems here.
Why should we require lower case?
64-bit stubs are interoperable with pre-4.19 implementations as long
as they do not address memory beyond 4GB. 64-bit stubs with higher
requirements should be debugged by gdb-4.19 or newer.
This would be making some promises that I'm not sure we're prepared
to deliver on. For one thing, there are machines with random combos
of 32- and 64-bit features that should be handled better, most
infamously Mips. A properly extended protocol will need to handle
this by interacting with the stub.
3.3. Threads
Gdb allows stub to select its own way of identifying threads. It allocates
64-bit unsigned integers for thread representation. It worth noting, however,
it worth noting that pre-4.19 would not properly process 64-bit
thread_ids >= 0x80000000.
Thread_id 0xffffffffffffffff should not be used, gdb reserves it for
ALL_THREADS thread id. This is a thread designation for all threads
on the remote system. It is used in cases where stub does not support
threads or to specify command/condition applicable to all threads.
Do we have consensus on thread representation yet? I was still thinking
about it myself...
There is run length encoding scheme defined for ASCII encoded packets,
it is implemented by many receivers, however, it is not used.
Let's put it in or throw it out. This part of the spec needs to
be tightened up either way.
Packet length is limited to 400 bytes, there are attempts to
allow 400 bytes of data, there are number of bugs there, so
the safe bet is to accept 407 bytes and never send more than
400 bytes for the whole packet. The only exception are cases
where stub needs more than 400 bytes to to pack all its registers.
Gdb has a reliable method to detect this case.
We should make a decision and make the code conform. If stubs might
need more than 400 bytes, then 400 is not really the upper limit.
Ditto for 407. The old rule was to use the size of registers[], on
the theory that the stub would be sure to leave enough space to return
all registers, but that's no longer satisfactory either.
5.2. New Gdb and Old Stub
It is highly desireable to provide interoprability between pre-4.19
stubs an newer gdbs.
I would go further and say "absolutely required". After all, if we
can go and do a new protocol, why not start from scratch? The point
of using the existing protocol is compatibility, not innovation.
There are few issues here to be resolved
o Post-4.19 gdbs are much pickier with regard to the response
checking. Also, many pre-4.19 stubd do not properly support
'kill'.
It seems reasonable to provide backward compatibility mode
accounting for these differences, for example this mode could be
enabled by setting gdb variable 'pre419comaptible'.
Or conversely, have a "be-picky" variable that nobody will set. :-)
o Some stubs developed in pre-4.19 times are not able to properly
respond to '!' due to documentation bug. These stubs will respond
'noSupport' even if they are able to support extended operations.
It seems reasonable to cover this popular deviation with another
settable variable, e.g. 'forceextended' .
I'll have to think about this one - it sounds wrong.
o Some stubs developed in per-4.19 times are not able to properly
support per thread debugging.
It seems reasonable to cover this popular deviation with another
settable variable, e.g. 'forcenothreads'
What exactly are the older stubs unable to do?
Stan