This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Towards multiprocess GDB
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