Re: Multiprocess GDB, formal spec

Re: Multiprocess GDB, formal spec

[Marc Khouzam]

Hi,

(side note, anyone know how I can keep a thread going, when I don't have
the original email?  Here, I'm trying to reply to
http://sourceware.org/ml/gdb/2008-08/msg00169.html , but I'm going to
end up creating a new thread :-( )


> On Wed, 13 Aug 2008 15:16:02 Stan Shebs wrote:
> The following writeup is a more formal specification for multiprocess
GDB. 
[...]
>
> * The GDB/MI Interface
> [TBD]
> 
> ** Planned limitations of the first version
> [...]
> The MI interface is not supported.

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

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

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.

As the multi-process work seems to be progressing quite well, I was
wondering if it was time to 
start looking at MI again?

Thanks

Marc

Re: Multiprocess GDB, formal spec

[Joel Brobecker]

> (side note, anyone know how I can keep a thread going, when I don't have
> the original email?  Here, I'm trying to reply to
> http://sourceware.org/ml/gdb/2008-08/msg00169.html , but I'm going to
> end up creating a new thread :-( )

There is a link at the top to the text-version of the mail (Other
format: [Raw text]). It's in mbox version, so you should be able
to import that email into your mailer.  I also keep a copy of
all emails sent to these mail-lists, so I can bounce you a copy of
the email if you tell me which one...

-- 
Joel

Getting old emails from mailing list (was:RE: Multiprocess GDB, formal spec)

[Marc Khouzam]

Sorry to those that know this already.  See below.

> -----Original Message-----
> From: Joel Brobecker [mailto:brobecker@adacore.com] 
> Sent: Monday, October 20, 2008 11:38 AM
> To: Marc Khouzam
> Cc: gdb@sourceware.org
> Subject: Re: Multiprocess GDB, formal spec
> 
> > (side note, anyone know how I can keep a thread going, when 
> I don't have
> > the original email?  Here, I'm trying to reply to
> > http://sourceware.org/ml/gdb/2008-08/msg00169.html , but 
> I'm going to
> > end up creating a new thread :-( )
> 
> There is a link at the top to the text-version of the mail (Other
> format: [Raw text]). It's in mbox version, so you should be able
> to import that email into your mailer.  I also keep a copy of
> all emails sent to these mail-lists, so I can bounce you a copy of
> the email if you tell me which one...

I just found out you can request the mailing list to send you old
copies of an email!  Then you can reply to that and keep the thread
going.  This is what I'm doing right now (but maybe changing the
subject will screw it up..., let's see).

(To find a message number, use the [Raw text] link on the web interface.
The number is on the first line)

==
To get messages 123 through 145 (a maximum of 100 per request), mail:
   <gdb-get.123_145@sourceware.org>

To get an index with subject and author for messages 123-456 , mail:
   <gdb-index.123_456@sourceware.org>

They are always returned as sets of 100, max 2000 per request,
so you'll actually get 100-499.

To receive all messages with the same subject as message 12345,
send an empty message to:
   <gdb-thread.12345@sourceware.org>
==

Marc

Re: Getting old emails from mailing list (was:RE: Multiprocess GDB, formal spec)

[Christopher Faylor]

On Thu, Dec 03, 2009 at 09:55:15AM -0500, Marc Khouzam wrote:
>Sorry to those that know this already.  See below.
>
>> -----Original Message-----
>> From: Joel Brobecker
>> Sent: Monday, October 20, 2008 11:38 AM
>> To: Marc Khouzam
>> Subject: Re: Multiprocess GDB, formal spec
>> 
>> > (side note, anyone know how I can keep a thread going, when 
>> I don't have
>> > the original email?  Here, I'm trying to reply to
>> > http://sourceware.org/ml/gdb/2008-08/msg00169.html , but 
>> I'm going to
>> > end up creating a new thread :-( )
>> 
>> There is a link at the top to the text-version of the mail (Other
>> format: [Raw text]). It's in mbox version, so you should be able
>> to import that email into your mailer.  I also keep a copy of
>> all emails sent to these mail-lists, so I can bounce you a copy of
>> the email if you tell me which one...
>
>I just found out you can request the mailing list to send you old
>copies of an email!  Then you can reply to that and keep the thread
>going.  This is what I'm doing right now (but maybe changing the
>subject will screw it up..., let's see).
>
>(To find a message number, use the [Raw text] link on the web interface.
>The number is on the first line)
>
>==
>To get messages 123 through 145 (a maximum of 100 per request), mail:
>   <gdb-get.123_145@sourceware.org>
>
>To get an index with subject and author for messages 123-456 , mail:
>   <gdb-index.123_456@sourceware.org>
>
>They are always returned as sets of 100, max 2000 per request,
>so you'll actually get 100-499.
>
>To receive all messages with the same subject as message 12345,
>send an empty message to:
>   <gdb-thread.12345@sourceware.org>

That doesn't always work because the mailing list archives are not always
complete.

FYI.

cgf

RE: Multiprocess GDB, formal spec

[Marc Khouzam]

Sorry again, just testing my theory about keeping a thread 
going from my previous post:
http://sourceware.org/ml/gdb/2009-12/msg00020.html
(didn't work when I changed the subject; I'm trying to see
if it works with the same subject)

> -----Original Message-----
> From: Joel Brobecker [mailto:brobecker@adacore.com] 
> Sent: Monday, October 20, 2008 11:38 AM
> To: Marc Khouzam
> Cc: gdb@sourceware.org
> Subject: Re: Multiprocess GDB, formal spec
> 
> > (side note, anyone know how I can keep a thread going, when 
> I don't have
> > the original email?  Here, I'm trying to reply to
> > http://sourceware.org/ml/gdb/2008-08/msg00169.html , but 
> I'm going to
> > end up creating a new thread :-( )
> 
> There is a link at the top to the text-version of the mail (Other
> format: [Raw text]). It's in mbox version, so you should be able
> to import that email into your mailer.  I also keep a copy of
> all emails sent to these mail-lists, so I can bounce you a copy of
> the email if you tell me which one...
> 
> -- 
> Joel
> 

RE: Multiprocess GDB, formal spec

[Marc Khouzam]

Bummer. Last test.

Re: Multiprocess GDB, formal spec

[Christopher Faylor]

On Thu, Dec 03, 2009 at 10:05:11AM -0500, Marc Khouzam wrote:
>Bummer. Last test.

Please don't use the mailing list as your test bed.

If you want to continue a discussion then either just change the subject
or, if you want to be really complete, add an In-Reply-To.

cgf

Re: 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

RE: Multiprocess GDB, formal spec

[Marc Khouzam]

 

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

RE: Multiprocess GDB, formal spec

[Marc Khouzam]

> From: Stan Shebs [mailto:stan@codesourcery.com] 
> Sent: Monday, October 20, 2008 11:53 AM
> 
> I have a set of patches applied to FSF GDB, and it generally 
> works, but there are, uh, some regressions. :-) 

Do you think this work will make it to HEAD before March next year?

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

So does Vladimir and/or yourself have plans for MI to be enhanced
correspondingly
by the time this feature makes it into HEAD?

Thanks for your input

Marc

Re: Multiprocess GDB, formal spec

[Stan Shebs]

Marc Khouzam wrote:
>> From: Stan Shebs [mailto:stan@codesourcery.com] 
>> Sent: Monday, October 20, 2008 11:53 AM
>>
>> I have a set of patches applied to FSF GDB, and it generally 
>> works, but there are, uh, some regressions. :-) 
>>     
>
> Do you think this work will make it to HEAD before March next year?
>   
I hope so! I'm down to about three main breakages to fix, and we have a 
design decision to make, namely whether to have a single target stack 
shared by multiple inferiors, or make multiple instances of the target 
stack.
>>> 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. :-)
>>     
>
> So does Vladimir and/or yourself have plans for MI to be enhanced
> correspondingly
> by the time this feature makes it into HEAD?
>   
Not me, at the moment anyway. It's a little too big to sneak in amongst 
my for-pay projects. :-)

Stan