This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Towards multiprocess GDB


Mark Kettenis wrote:
Date: Fri, 18 Jul 2008 13:40:08 -0700
From: Stan Shebs <stanshebs@earthlink.net>

CodeSourcery has a project to add "multiprocess" capability to GDB,
and with this message I'd like to kick off some discussion of what
that means and how to make it happen.

Please remind me, why was this a desirable capability again?
I thought everybody knew that from when I wrote it into the original GDB 5 wishlist back in 1995 or so. :-)
Personally, I can't imagine someone would really want to do this using
the traditional gdb CLI, at least not within a single gdb instance.
I'd simply fire up two (or more) xterms and debug the processes
seperately. One thing that could be useful though for that scenario
is the ability to hand of processes between gdb instances upon
fork/exec.
You hit on one of the reasons right there. Even the two-xterm case starts to involve some juggling, where you're trying to get to the other xterm and continue or whatever, before the first program times out. (At least I always seem to fumble the mouse clicking at that key point.) And if you've set the first program not to time out, then maybe you've changed its behavior in such a way as to suppress the bug. So the single GDB instance gives you tighter control over the several programs.

I think there also advantages in terms of sharing history, symbols, and so forth; "break foo" can be a very interesting way to discover which program's foo() gets hits first, for foo() in a shared library.
Adding a "multiprocess" capability to GDB is almost certainly going to
add significant complexity. So there should be a good motivation for
it.
I'm not sure it's going to be that big of a change actually. Once behavior has been directed to the right objects internally, they will do what they're doing now. Most symbol handling is objfile-relative for instance, adding a new set of objfiles for a different exec isn't going to affect that code.

Stan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]