gdbserver: integrated vs. separated

gdbserver: integrated vs. separated

[Daniel Jacobowitz]

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

Re: gdbserver: integrated vs. separated

[Kevin Buettner]

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

Re: gdbserver: integrated vs. separated

[Quality Quorum]

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

Re: gdbserver: integrated vs. separated

[Fabrice Gautier]

On Fri, 20 Jul 2001 14:31:33 -0700
Daniel Jacobowitz <dmj+@andrew.cmu.edu> 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.

Did you lok at the multi-thread problem ?

I take some times to look at it, tried various ways, but neither the
"toward" or "away" look easy to go. It's mostly my first try to hack at
gdb and it's not an easy thing i guess, but here are some thoughts:

Currently the code handling threads for linux is in lin-lwp.c (there is
also lin-thread.c or linux-thread.c but they seem deprecated). If you 
are going to take the "away" way i think you will have to duplicate most
of the code in there. But it's linked with other part of gdb:

- It's using comodity functions (such as fprintf_unfiltered), shouldn't
  be a big problem.

- It's using directly thread.c functions (such as add_thread) to change
  the gdb view of threads. This should go away in gdbserver.
  
- a bunch of other target functions (such as child_resume,
  child_xfer_memoryfecth_inferior_register...). 
  
- Some functions about ptid, pid, tid 

- it's using a bunch of signal related function.


So many things i'm not enough familiar with to know what way is best to
go...



-- 
Fabrice Gautier <gautier@email.enstfr>