From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15741 invoked by alias); 20 Oct 2008 16:23:42 -0000 Received: (qmail 15732 invoked by uid 22791); 20 Oct 2008 16:23:41 -0000 X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Oct 2008 16:22:46 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m9KGMfWl005357; Mon, 20 Oct 2008 11:22:42 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 11:22:41 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiprocess GDB, formal spec Date: Mon, 20 Oct 2008 16:23:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA0653C149@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <48FCA958.3060805@codesourcery.com> References: <6D19CA8D71C89C43A057926FE0D4ADAA0653C051@ecamlmw720.eamcs.ericsson.se> <48FCA958.3060805@codesourcery.com> From: "Marc Khouzam" To: "Stan Shebs" Cc: X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00077.txt.bz2 =20 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=20 > multiprocess > >>=20=20=20=20=20 > > 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 :-) > >=20=20=20 > I have a set of patches applied to FSF GDB, and it generally=20 > works, but=20 > there are, uh, some regressions. :-) I wasn't going to make a=20 > branch for=20 > them pre-submission, but could be persuaded if everyone=20 > promises not to=20 > 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=20 > MI support > > for such features. > > I was just wondering how come there were not more MI=20 > details included, > > considering there > > was already a post for Multiprocess MI extensions: > > http://sourceware.org/ml/gdb/2008-06/msg00080.html > >=20=20=20 > This goes back to the multi-exec / multi-process distinction.=20 > Those MI=20 > extensions are for multiple-process single-executable debugging.=20=20 > Multiple executables introduces a whole new class of confusions,=20 > 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,=20 > > 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=20 > 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=20 > multi-process > > parts of MI, before > > they are released officially. > >=20=20=20 > This is the perfect place to discuss. It certainly wouldn't=20 > be the first=20 > time we've talked about features of GDB versions that we=20 > don't yet have=20 > in hand! Great! > > As the multi-process work seems to be progressing quite well, I was > > wondering if it was time to=20 > > start looking at MI again? > >=20=20=20 > Yes, now would be a good time. I had to neglect MI due to time=20 > constraints on this project, but after people try their hand=20 > at juggling=20 > a half-dozen programs through the command line, I think an MI=20 > 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=20 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,=20 there are commands which apply to a process in general but no=20 specific thread. It seems like 'focus' would allow GDB to know which=20 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,=20 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