Multiprocess GDB, formal spec

[Stan Shebs]

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