Re: gdbserver: integrated vs. separated

[Quality Quorum <qqi at world dot std dot com>]

On Fri, 20 Jul 2001, Daniel Jacobowitz wrote:

> 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 suppose it is a right thing to do.

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

Thanks,

Aleksey