Re: gdbserver: integrated vs. separated

[Fabrice Gautier <gautier@email.enst.fr>]

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>