From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5200 invoked by alias); 16 Mar 2007 23:43:19 -0000 Received: (qmail 5192 invoked by uid 22791); 16 Mar 2007 23:43:18 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 16 Mar 2007 23:43:13 +0000 Received: from kahikatea.snap.net.nz (218.60.255.123.dynamic.snap.net.nz [123.255.60.218]) by viper.snap.net.nz (Postfix) with ESMTP id 305B73D8B7D; Sat, 17 Mar 2007 12:43:09 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 24CB14F740; Sat, 17 Mar 2007 12:43:06 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17915.11142.366839.850920@kahikatea.snap.net.nz> Date: Fri, 16 Mar 2007 23:43:00 -0000 To: Denis PILAT Cc: gdb-patches Subject: Re: New mi commands for threads In-Reply-To: <45FA57F0.4030107@st.com> References: <45F8200A.3000305@st.com> <17913.46746.760751.573314@kahikatea.snap.net.nz> <45FA57F0.4030107@st.com> X-Mailer: VM 7.19 under Emacs 22.0.95.4 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00156.txt.bz2 > > Lists use square brackets, information on each thread should be enclosed in > > curly brackets: > > > > threads=[{thread-id="6",frame={...},thread-extra-info="bla"},{thread-id="5",frame={...},thread-extra-info="bla"},...] > > > > I guess your output has been manually generated as thread-id="1" seems to > > duplicate some information. > This output is a side effect of the frame printing, the actual > -thread-select command has the same. I'm going to have a look at how we > can avoid it, but I think it will impact *-thread-select* as well. OK, I dodn't realise that. Interestingly the example in the manual doesn't show the duplicate information (or the fullname field, so it will have to be updated). It seems to due to the fact that do_captured_thread_select uses SRC_AND_LOC, while the other MI commands use LOC_AND_ADDRESS. I see that normal_stop specifies LOC_AND_ADDRESS specifically for MI. It looks a bit of a hack but perhaps we should do the same for do_captured_thread_select: /* For mi, have the same behavior every time we stop: print everything but the source line. */ if (ui_out_is_mi_like_p (uiout)) source_flag = LOC_AND_ADDRESS; > About brackets, I see how they were used in *-thread-list-ids*, > according to your comment, this one should use square brackets as well, > am I right ? Yes, I think it, should but we probably shouldn't change it until we bump the MI level. It's probably a legacy from mi0 when all brackets were curly ones. > About position of "number-of-threads" and "current-thread-id", I prefer > them in front as well, but that would be not consistent with > -thread-list-ids. But do we care about consistency with this one that > seems to be not consistent with the MI list format ? Well one lists threads and the other lists thread ids, so I don't see a problem. > > I thought that the frame information was expensive to get and that it was > > agreed you could get it, if needed, using other MI commands anyway. > Yes it is, but I want to get rid of CLI commands and for front ends that > want to get all informations, they could use this command if they need > extra information. But I can add an option to include or not these > information. > For remote (or on board) debugging, our front ends will emit > *-thread-list-ids* to get only the list, and then *-thread-info* to > focus only on the current thread. OK, I see now. -- Nick http://www.inet.net.nz/~nickrob