Re: Multiprocess GDB, formal spec

Stan Shebs
2008-10-20T15:53:57Z

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