Re: Towards multiprocess GDB

[Stan Shebs <stan@codesourcery.com>]

Michael Snyder wrote:
> Yarg.  I can imagine wanting to debug several core files at once
> (failure of a multi-process application, maybe), but mixed core
> files and live processes?  I think maybe we should disallow that...
> What would happen when you said "continue"?
>   
In practice, I think there are going to be nonsensical combinations, but 
we can just exclude them as they come up. For a first version it seems 
reasonable to only work if all the arguments use the same target, and 
then allow more variation once Pedro implements the multi-target 
capability he described. :-) If targets are per-program, then "all 
continue" could be quite a circus - no effect on cores, ptrace calls to 
local inferiors, and a spray of packets to remote targets, which are 
fortunately async, so they don't mind getting an extra continue packet 
or two. :-)
> How about this as a first increment?  Could we extend
> what we now have with forks, so that GDB could individually
> control the separate process ids (including threads, if they
> have them), while forestalling dealing with separate symbol
> files because forks can all share the same one?
>   
I want to jump on symbol files quickly, because I think it may be the 
long pole - I hope not, but we don't know for sure yet, lots of old code 
with old assumptions. Our clientele is mainly interested in embedded 
(more protocol and gdbserver hackery, whee), so native fork support 
seems most likely as either testing support or a volunteer contribution.

Stan