From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabrice Gautier To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: gdbserver: integrated vs. separated Date: Fri, 20 Jul 2001 18:47:00 -0000 Message-id: <20010721030902.01E7.GAUTIER@email.enst.fr> References: <20010720143133.A32237@nevyn.them.org> X-SW-Source: 2001-07/msg00306.html On Fri, 20 Jul 2001 14:31:33 -0700 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. 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