Re: Towards multiprocess GDB

[Stan Shebs <stan@codesourcery.com>]

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