gdbserver: integrated vs. separated

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>]

Before I invest any more time in patching gdbserver, I think I need to
know which way to take it: towards GDB or away from.

Andrew Cagney wrote, in a message not long ago:
 > I think, in terms of better splitting up gdbserver and gdb it is pretty
 > much a requirement.  I can but dream of the day when GDBSERVER stops
 > including defs.h :-)


Well, I can't dream of it - I can see it.  KERNEL_U_ADDR, a few
*_REGNUM variables, REGISTER_BYTES/REGISTER_RAW_SIZE/REGISTER_BYTE, and
some prototypes are all it's currently getting from defs.h.  I've
removed the include entirely in my local sources.  It'll take some
weeding to make all the gdbserver ports (or at least most of them)
compile in this situation, but it can be done.  Right now I still get
CORE_ADDR by including "bfd.h", but I can probably make that go away
too.

The question is, should I do all this, or should we go the other way? 
I think splitting is the only reasonable answer, and I think that it
will simplify gdbserver substantially in addition to forcing me to
improve documentation of the remote protocol.

If the world agrees with me, I'll do the cleanup necessary and work out
a postable solution.  My extreme temptation is to move gdbserver to a
separate top-level directory; then we can enforce independence from
gdb's private headers, and perhaps put things like the target_signal
enum and definitions of remote protocol register packets in include/
(or include/gdb/?).

I'm probably going to break a couple of gdbserver targets in the
process, for lack of testing ability; I can't find a lot of these
systems to test on.  I have my doubts about when they last built,
though, so it doesn't make me weep.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer