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


[List pruned a little :-)]

Quality Quorum wrote:

> Hi,
> 
> I am working on implmenting standard compliant remote.c and gdbserver.
> I found just a few problems with protocol specs so far. 
> 
> 1. There is no need in 'isThreadAlive' request: remote.c has to maintain 
>    local cache of available threads, which is updated by 'threadListQuery'
>    if required (I tried a few variants implementing thread list 
>    synchronization and it seems this one is the most rational).
> 
>    Target methods xxx_is_thread_alive and xxxxx_find_new_thread 
>    are simply using this cache without generating any traffic
>    on the wire.
> 
>    So. 'itThreadAlive' is depreciated.
> 
> 2. I misread code implementing 'addBWPoint' and 'deleteBWPpoint', 
>    so the description was incorrec, it is fixed now.
> 
> I put updated document at http://www.std.com/qqi/ftp/protocol.txt .
> 
> I put updated rproxy at http://www.std.com/qqi/labslave/rproxy.html .
> 
> It is now running on WinNT and sipports Wiggler among other things - 
> I tried it with MPC860ADS.  It will be not too complicated to add 
> other processors, however, I do have 68360 based board only and no 
> other wigglers. I have ICD cable which I am using under linux,
> I am planning to provide a target under linux using ICD cable to 68360.
> 
> Please, be forgiving: WinNT stuff is barely in alpha state, rest is
> barely in beta. 
> 
> I have nagging outstanding problem: I do not know what paperwork and 
> what changes in the files I have to make in order to turn it over 
> to FSF. I signed and submitted the most appropriate paper I found on
> gnu website, however, I did not hear from them yet and it seems to me
> that it will not be enough.
> 
> Can any kind soul help me with this ?


Just FYI, there are several things that we're going to need to keep in
mind if this is to go forward.


As a general comment, its good to at least see someone with the energy
to pursue the gdbserver/stub code so that there is a generic (and
correct!) stub reference implementation available.  The fact that you're
hammering the external side is (as they say in the USofA) cool.

When it comes to things like the remote protocol spec and remote.c, you
might need to take a little care and think about what you want to do
with the work in the longer term.  To that end, I've some notes on both
remote.c and the spec below.

[[As an aside, I'm away for much of January, because of that and because
you appearing to be moving at a rapid rate of knots, I'm going to try to
be fairly to the point with the problems we're going to encounter.  That
way, I'm hopefully avoiding the possibility of you doing much
significant work that, unfortunately, ends up in limbo.]]

	Andrew

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).

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.


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.

	Take care,

		Andrew

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