From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kevin Buettner <kevinb@cygnus.com>
To: Daniel Jacobowitz <dmj+@andrew.cmu.edu>, gdb@sources.redhat.com
Subject: Re: gdbserver: integrated vs. separated
Date: Fri, 20 Jul 2001 15:00:00 -0000
Message-id: <1010720220022.ZM8037@ocotillo.lan>
References: <20010720143133.A32237@nevyn.them.org> <dmj+@andrew.cmu.edu>
X-SW-Source: 2001-07/msg00302.html

On Jul 20,  2:31pm, 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.

My opinion at this point is that gdb and gdbserver should be separated
as much as possible.

My concerns over a tightly integrated solution are as follows:

 - It might make development of both gdbserver and gdb more difficult.
   I.e, suppose you're working on gdbserver and wish to make an
   architectural change.  Not only will you have to study the ramifications
   of the impact on gdbserver, but you'd have to do it for all of gdb
   as well.  From the other side (development of gdb), there may be
   some goals that gdbserver strives for (small memory footprint) that
   gdb might not care about so much.  Thus, a perfectly workable
   solution for gdb alone might be discarded due to the fact that
   the design also has to take gdbserver's requirements into account.
 
 - gdbserver will frequently become broken due to changes in gdb.

 - gdbserver will bloat making it unusable in some environments.

 - gdbserver will require significantly more code than it formerly
   did making it more difficult to bring up a quick and dirty gdbserver
   for a new port.

Kevin