This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: PATCH: Multithreaded debugging for gdbserver
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Tue, 11 Jun 2002 13:45:31 -0400
- Subject: Re: PATCH: Multithreaded debugging for gdbserver
- References: <20020609223833.GA2504@nevyn.them.org>
On Sun, Jun 09, 2002 at 06:38:33PM -0400, Daniel Jacobowitz wrote:
> I've promised this patch, at one time or another, to quite a few people. I
> promised most of them specific dates, too. My apologies to all of them;
> next time I won't give you a date :)
>
> There's a few minor FIXMEs left; for instance, I use a wait/sleep loop
> instead of sigsuspend in the clever way that thread-db.c in GDB does. But
> they are all fairly minor. Five architectures are supported: PowerPC, MIPS,
> i386, SH, and ARM. Others will come as time permits, or as volunteers step
> up; it's really quite easy. Three functions, a constant, and one small
> variable is all it took for four of those five.
>
> To use it, you need a copy of the target libraries with symbol information,
> in the appropriate filesystem layout. Then you need to set
> solib-absolute-prefix appropriately. Also, libthread_db now must be present
> on the target system and also at configure time for gdbserver.
>
> BE SURE to use the right libraries, or something will almost assuredly
> segfault. I'm working on making that less fragile.
>
> Left out of this patch are the client parts which require protocol changes;
> namely async thread notification and accurate single-thread stepping. The
> former was turned down in favor of a synchronous mechanism (which will
> require extensive GDB client changes, I believe, and be somewhat more
> brittle, but has its own advantages) and the latter received no serious
> comments.
>
> Also left out are the tests, since they depend on the remote testing patches
> I posted four or so months ago.
>
> I intend to commit this in two or three days unless something comes up with
> the patch (along with a suitable NEWS entry). Longest changelog I ever
> wrote, I think - 150 lines at last count.
Committed.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer