Multiprocess GDB, formal spec

Stan Shebs
Mon Oct 20 15:53:00 GMT 2008

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:
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. :-)


More information about the Gdb mailing list