RE: Multiprocess GDB, formal spec

["Marc Khouzam" <marc dot khouzam at ericsson dot com>]

Stan Shebs wrote:
> 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.

I wish I had more time to spend on this, but in my case,
such fun will have to wait until at least the new year...
But my interests in reading about developments remains :-)

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

Maybe some extentions to the MI extensions is the way to go :-)

> > 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!

Great!

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

And I'm hoping we can get DSF-GDB to support this quickly after.

So, the good news is that the proposed MI extensions posted by Volodya
http://sourceware.org/ml/gdb/2008-06/msg00080.html 
are quite good and provide almost all of what I needed for the frontend.

The missing part (which triggered this post), is the support for the
'focus' command described in this specification.   For multi-process, 
there are commands which apply to a process in general but no 
specific thread.  It seems like 'focus' would allow GDB to know which 
process those commands should affect.  Is this correct?

For non-stop, MI was enhanced quite nicely with the --thread/--frame
generic options.  From what I have experienced in adapting DSF-GDB for
mutli-process, it would be good to have a similar generic way to specify
the process (if no thread is specified.)

In a previous post, Pawel suggested to use the same name space to
describe
processes and threads.  That way, the --thread option could be used with
either
a thread or a process, in a very generic fashion.

For example, in the case of multiple-processes and reading memory, a
user
may simply request to read the memory of a specific process at an
address, 
without specifying any thread.  It would be nice to be able to specify
this in MI.

One of the issues is that it does not seem entirely clear (maybe just to
me),
what set of commands will eventually apply to a process only.

Thanks

Marc