This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Multiprocess GDB, formal spec
Marc Khouzam wrote:
On Wed, 13 Aug 2008 15:16:02 Stan Shebs wrote:
The following writeup is a more formal specification for multiprocess
First let me say that I think the proposal (snipped out) is very
interesting and I'm looking forward
to the GDB version that will implement it :-)
I have a set of patches applied to FSF GDB, and it generally works, but
there are, uh, some regressions. :-) I wasn't going to make a branch for
them pre-submission, but could be persuaded if everyone promises not to
laugh at the code.
Now, as a frontend developer, am I very interested with the MI support
for such features.
I was just wondering how come there were not more MI details included,
considering there
was already a post for Multiprocess MI extensions:
http://sourceware.org/ml/gdb/2008-06/msg00080.html
This goes back to the multi-exec / multi-process distinction. Those MI
extensions are for multiple-process single-executable debugging.
Multiple executables introduces a whole new class of confusions,
especially on the symbol side.
Furthermore, I find myself in a strange situation where I have been
working with a preliminary,
non-public version of GDB which has some support for multi-process
through MI. This support, will
eventually (I believe) makes its way to mainline GDB. But until then, I
am not sure where
I can discuss/comment on my experience using the 'proposed' MI
extensions. Because of
the intended use of MI, it greatly benefits from respecting
backwards-compatibility, which
implies that it would be beneficial to update/modify the multi-process
parts of MI, before
they are released officially.
This is the perfect place to discuss. It certainly wouldn't be the first
time we've talked about features of GDB versions that we don't yet have
in hand!
As the multi-process work seems to be progressing quite well, I was
wondering if it was time to
start looking at MI again?
Yes, now would be a good time. I had to neglect MI due to time
constraints on this project, but after people try their hand at juggling
a half-dozen programs through the command line, I think an MI
alternative is going to get considerable interest all of a sudden. :-)
Stan