This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdbserver: integrated vs. separated
- To: Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>, gdb at sources dot redhat dot com
- Subject: Re: gdbserver: integrated vs. separated
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Fri, 20 Jul 2001 15:00:22 -0700
- References: <20010720143133.A32237@nevyn.them.org>
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