Re: Current (non-) state of gdbserver

[Andrew Cagney <ac131313@cygnus.com>]

> Based on the lack of response I got last time I inquired about gdbserver,
> I'd say that no one has really picked it up since Stan stepped back.  It
> hasn't built in a while; the multiarch support completely stops it from
> working, on the targets I tried at least (ppc-linux and mips-linux).


That is a fair assesment.


> Unless someone steps up with something already done (if you're out there,
> we're waiting...), I'm going to start working on this.  I'm not sure how
> multiarch will fit in to gdbserver in the future, but for now my intent is
> to bloat it somewhat with the necessary support code.  It'll probably
> involve splitting a lot of tdep files into two pieces.


 From memory, gdbserver uses very little from tm-*.h and *-tdep.c.  The 
main thing is the description of the remote protocol G packet.  I think 
that protocol packet should be published (it is a GDB interface) in a 
way that lets both GDBSERVER and the *-tdep.c files use it.

I don't know that trying to split the tdep file will actually help that 
much.  I've tried building GDBSERVER using the bloat technique - gave up 
when I found something was trying to suck in top.c ....


> I'd also like to start building gdbserver by default on platforms which
> support it (and I have patches to extend the list a bit).  That way we can
> at least notice this sort of thing...


Check the threads:

disable gdbserver for cross builds

http://sources.redhat.com/ml/gdb-patches/2000-09/msg00170.html


[RFA]: Add gdbserver to configdirs for several targets
http://sources.redhat.com/ml/gdb-patches/2000-11/msg00393.html

	Andrew