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>
- Subject: Re: gdbserver: integrated vs. separated
- From: Fabrice Gautier <gautier at email dot enst dot fr>
- Date: Sat, 21 Jul 2001 03:46:47 +0200
- Cc: gdb at sources dot redhat dot com
- References: <20010720143133.A32237@nevyn.them.org>
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>