This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: gdb remote protocol, winnt, wigglers
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: gdb remote protocol, winnt, wigglers
- From: Quality Quorum <qqi at world dot std dot com>
- Date: Wed, 5 Jan 2000 08:16:42 -0500 (EST)
- cc: gdb at sourceware dot cygnus dot com, Leon Pollak <leonp at plris dot com>
On Wed, 5 Jan 2000, Andrew Cagney wrote:
> Just FYI, there are several things that we're going to need to keep in
> mind if this is to go forward.
Thanks,
> Spec:
>
> The current ``official'' protocol spec is in the GDB user guide. (As an
> aside, it wasn't put in the internals manual as it was documenting an
> external interface.)
>
> Rather than end up with two possibly conflicting definitions, its
> obviously going to be better if there was only one definition of the
> protocol. To that end, you many want to first think about how to
> re-structure (before re-wording) the protocol spec. Should it go into a
> separate chapter or as an appendix / attatchment? It's actually Stan
> Shebs decision (as the doco maintainer).
It is up to you, guys. I hope I put together something which has enough
meat in it to be used as a more formal base for any discussion
about possible protocol changes. How, it is going to be used I do not care
much.
Also, I am not a native English speaker, so any writing is a big pain
for me and its quality is low. So, I prefer to do as little writing
as possible.
> With the higher level stuff out the way, it will become possible,
> through a series of patches, to evolve the current spec into something
> better.
>
> FWIW, I'm strongly against simply replacing the existing spec with a new
> one. I'd like to be able to see (using CVS diff) what was changed at
> each point so that any problems/issues can be traced down and then
> fixed.
Why not. IMHO, the only problems with current spec are that (1)it is not
clear enough and (2)it is not sufficient to support threads, (3)some
pieces (e.g. Hc) are unimplementable on remote stub. I really do not care
in what form it should be fixed, however, it should be fixed.
>
>
> remote.c:
>
> Beware, remote.c's underlying architecture is in a state of flux.
>
> Of the possible targets to async first remote was selected as it wasn't
> going to affect native targets and was entirely self contained (also it
> didn't involve signals or ptrace). It turned out that it had some of the
> more complex interactions but that is another story. :-)
>
> The consequence is that remote.c currently contains two remote targets:
> remote / extended-remote and async / extended-async. Once all the async
> issues are resolved, the old code will be given the flick. If you've
> been looking through remote.c you'll have noticed the FIXME's I've added
> as place holders while other async code is finished.
>
> If you're looking to re-do remote.c you'll need to keep in mind that
> file is going to continue to receive major changes and those changes
> will, unfortunately, take priority over anything else (sigh). If you're
> able to submit small and distinct patches then there is a really high
> likelihood of your work being accepted quickly and that will allow the
> work to keep reasonably in sync with the mainline code.
I am a stub developer and I prefer to do nothing about remote.c .
However, I do not feel that protocol-wise it is moving in a right
direction, so I am addressing this issue by writing reference
implementation of remote.c to be used ONLY as a working protocol
reference. It is going to support only one target `remote' with
autosensing of extended ops support. And again I really do not care
how it is going to be used. I suppose bits and pieces of it
will be propagated into mainstream and or just it will be used
as a protocol reference.
> Andrew
Thanks,
Aleksey