From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19979 invoked by alias); 23 Sep 2006 19:06:40 -0000 Received: (qmail 19971 invoked by uid 22791); 23 Sep 2006 19:06:39 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 23 Sep 2006 19:06:37 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k8NJ5vM3001044; Sat, 23 Sep 2006 21:05:57 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.8/8.13.6) with ESMTP id k8NJ5vou008714; Sat, 23 Sep 2006 21:05:57 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id k8NJ5ucX001839; Sat, 23 Sep 2006 21:05:56 +0200 (CEST) Date: Sat, 23 Sep 2006 19:06:00 -0000 Message-Id: <200609231905.k8NJ5ucX001839@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: nickrob@snap.net.nz, denis.pilat@st.com, gdb@sourceware.org In-reply-to: <20060919210316.GA17479@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 19 Sep 2006 17:03:16 -0400) Subject: Re: info thread References: <17679.5055.729126.253019@kahikatea.snap.net.nz> <450FED7C.1050902@st.com> <17680.22719.512121.415472@kahikatea.snap.net.nz> <20060919210316.GA17479@nevyn.them.org> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00138.txt.bz2 > Date: Tue, 19 Sep 2006 17:03:16 -0400 > From: Daniel Jacobowitz > > This isn't really relevant. It breaks down into just a few parts in GDB > parlance: > > - The GDB ID. That's "1", "2", et cetera in your example. > - The thread ID, produced by to_pid_to_str, e.g. "Thread -BLAH (LWP > BLAH)". This is just a string. > - The thread extra info. Not present in your example, but e.g. > "(Exiting)" or "(not ready)". > - The thread's current stack frame. > > That last, I think, is not useful in MI. There's commands to fetch it > when it's wanted, and it might not be by some consumers. And it will > show up with -thread-select already. So, I would recommend including > only the GDB ID (as from -thread-list-ids) and the additional > information. Note that the formatting of the thread ID produced by to_pid_to_str is highly dependent on the specific threads model in use. The thread extra info is also mostly free-form. That means it might not be wise to export that information in the MI interface. Mark