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: gdb remote protocol, winnt, wigglers




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



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