This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Current (non-) state of gdbserver
- To: Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>
- Subject: Re: Current (non-) state of gdbserver
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 11 Jul 2001 13:36:41 -0400
- Cc: gdb at sources dot redhat dot com
- References: <20010710234505.A5814@nevyn.them.org>
> 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