Re: Current (non-) state of gdbserver

[Stan Shebs <shebs at apple dot com>]

Daniel Jacobowitz wrote:
> 
> 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).
> 
> 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.

As Andrew observes, you'll probably get tangled up in dependencies,
but those are likely to be mistakes in GDB's architecture - there's
no good reason why lowest-level native and target support (which is
all that gdbserver needs) has to be making references to user-interface
code and the like.

Thought 1: split the arch vector into a general vector and a nano-vector
with only the register definitions and such.  If we really don't care
about the extra footprint from unused arch code (either because it's
small, or we know linker will discard), then instead you could have
an optional <arch>-ui.c to be a home for target-specific commands.

Thought 2: foo-nat.c will probably need to be split, again foo-ui.c
could be a home for higher-level and symbolic stuff.

Thought 3: AIX is especially ugly to handle, because you need to make
a ptrace call and pick apart OS-supplied structures even to find the
entry point.  Might even need a protocol addition to get it to work.

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

An excellent idea.  One thing I wanted to do as part of this was to
move gdbserver out of its subdirectory, since by the time you're
done integrating with the rest of GDB sources, you should only have
one file unique to gdbserver (main()), and the semi-duplicated
Makefile.in make trouble.

Stan