From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 357173850226; Fri, 18 Aug 2023 12:08:31 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 357173850226
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1692360511;
	bh=Hth3LugyIJuIFcBEIr8C1Pv0PDk5dQE65ZvGPU/fWq8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ChyhXU7PqfBw9RgEhFs3clwF1KSX+yOC3g35cwPnwDr3/mLksDQXwWD+w/m6A/VDS
	 831xczDwkQMRJ1p3UtqNpyCNIMiaWuLD/m5g3628CEquSBnRH6a4yNMIUI0MyfPtQs
	 c0Xt55H93rAde8IRWy51y4rDzXIHn7DY43K21w7k=
From: "moshe.rubin at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug cli/30771] GDB needs a silent thread-selecting command akin to
 "select-frame"
Date: Fri, 18 Aug 2023 12:08:30 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: cli
X-Bugzilla-Version: 8.2.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: moshe.rubin at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-30771-4717-erhdxPlZJa@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-30771-4717@http.sourceware.org/bugzilla/>
References: <bug-30771-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D30771

--- Comment #6 from Moshe Rubin <moshe.rubin at gmail dot com> ---
You were right - a local "pipe" custom command was getting automatically
loaded.  Sorry about that <g>.

Examining its code, and that of other solutions for passing internal command
output to an external program (https://stackoverflow.com/a/50359976), they =
all
suffer from the same drawback that they use gdb.execute(cmd, to_string=3DTr=
ue)
and then pipe the output to the external tool. gdb.execute("thread 2",
to_string=3DTrue) returns the output as a string, but also displays it to t=
he
screen.  The fact that gdb.execute(<cmd>, to_string=3DTrue) does not always
suppress screen output is a bug and should be fixed.created and fixed.

However, thanks to your comment about InferiorThread.switch(), I believe we
have a solution, even for gdb 8.2!

In my case, when gdb opens my core, I want to iterate over all threads in it
(i.e., the current inferior) without any screen output.

To determine the number of threads in the current inferior:

    (gdb) python print(len(gdb.selected_inferior().threads()))
    17

>From the gdb command prompt, select each thread one at a time by specifying=
 the
target thread object and calling the switch() function:

    (gdb) python gdb.selected_inferior().threads()[0].switch()
    (gdb) thread
    [Current thread is 17 (LWP 631)]
    (gdb) python gdb.selected_inferior().threads()[1].switch()
    (gdb) thread
    [Current thread is 16 (LWP 630)]
    (gdb) python gdb.selected_inferior().threads()[2].switch()
    (gdb) thread
    [Current thread is 15 (LWP 629)]
    . . .
    (gdb) python gdb.selected_inferior().threads()[16].switch()
    (gdb) thread
    [Current thread is 1 (LWP 598)]
    (gdb)

The main thing to note is the ability to switch/select a different thread w=
ith
*no* screen output.

Kudos and thanks to you, Tom, for suggesting this power user method.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=