From: Dov Grobgeld via Gdb <gdb@sourceware.org>
To: "Ijaz, Abdul B" <abdul.b.ijaz@intel.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>,
"Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>,
"Schimpe, Christina" <christina.schimpe@intel.com>,
"Metzger, Markus T" <markus.t.metzger@intel.com>,
"pedro@palves.net" <pedro@palves.net>,
Andrew Burgess <andrew.burgess@embecosm.com>,
"simon.marchi@polymtl.ca" <simon.marchi@polymtl.ca>,
"tom@tromey.com" <tom@tromey.com>
Subject: Re: [PING][RFC] New command "thread filter" in GDB
Date: Mon, 28 Oct 2024 15:41:34 +0200 [thread overview]
Message-ID: <CA++fsGEp5Mgikup1_4Dw4ojseSnGKBQu+YZFgz6o2M=h8T7Q=w@mail.gmail.com> (raw)
In-Reply-To: <SA1PR11MB6846C8F9920F56B751E13910CB4A2@SA1PR11MB6846.namprd11.prod.outlook.com>
Sounds useful!
I once wrote a related gdb command that I called "threadgrep" that
shows any thread (actually the corresponding "where" line) that in the
call stack has a match to a regular expression. I guess such
functionality could be implemented by your predicate() function.
Regards,
On Mon, Oct 28, 2024 at 1:58 PM Ijaz, Abdul B via Gdb
<gdb@sourceware.org> wrote:
>
> Ping.
>
> Thanks & Best Regards
> Abdul Basit
>
> From: Ijaz, Abdul B <abdul.b.ijaz@intel.com<mailto:abdul.b.ijaz@intel.com>>
> Sent: Wednesday, October 2, 2024 9:24 AM
> To: gdb@sourceware.org<mailto:gdb@sourceware.org>
> Cc: Aktemur, Tankut Baris <tankut.baris.aktemur@intel.com<mailto:tankut.baris.aktemur@intel.com>>; Schimpe, Christina <christina.schimpe@intel.com<mailto:christina.schimpe@intel.com>>; Metzger, Markus T <markus.t.metzger@intel.com<mailto:markus.t.metzger@intel.com>>
> Subject: [RFC] New command "thread filter" in GDB
>
> Hi All,
>
> I am writing to collect your feedback for the new command “thread filter”, we would like to introduce. This new command will process the input list of threads and then try to filter them if there is any expression in the input. So it print only filtered thread ids from the input list where the input expression evaluates to true. Here are some examples for the usage of this command:
>
>
> * thread filter 1-9
>
> * Outputs the ids of threads with single digit
>
> * thread filter all x > 10
>
> * Outputs the ids of threads in whose context the variable “x” is greater than 10.
>
> * thread filter 10-99 $_thread % 2 == 0
>
> * Outputs the ids of threads whose id is a two-digit even number.
>
> * thread filter all predicate()
>
> * Outputs the ids of thread for which the function “predicate” evaluates to true.
>
> * thread filter all workitem == 1234
>
> * Find the thread(s) for which the “workitem” variable has a specific value.
>
> Output of all these commands will be string type list of thread ids which may be used later for other commands like thread apply, info thread or further filtering. For example
>
> * thread filter all $_thread<5
>
> Filtered threads:
>
> $1 = “1 2 3 4”
>
>
> Examples of output usage in other command like “info thread” or “thread apply”:
>
> * info threads 1 2 3 4
>
> * “info thread” command print thread info for thread ids “1 2 3 4 5”
>
> OR
>
> * thread apply 1 2 3 4 p workitem
>
> * Print a variable with name “workitem” for all the threads matching ids filtered by the thread filter command.
>
> * Thread filter 1 2 3 4 workitem >2
>
> * Outputs the ids of thread from the input “1 2 3 4 5” list for which a variable “workitem” value is greater than 2.
>
> There is already a “thread find” command in GDB which filters using regex for some fields. It filters the thread(s) using fields like id, thread name etc. The output of this command is thread id, name and extra information. But this command is not able to filter using thread location, expression, private or convenience variables like shown above and also if there are many threads filtered then its output is not easy to reuse as an input for other commands. Like if someone want to get “info threads” or “thread apply” for all the filtered threads etc. Mentioning this, to clarify also whether it will be best to update the existing command or adding a new command would be fine. As extending the existing command will update the output of command. Example of the input and outputs of existing “thread find” command.
>
> (gdb) help thread find
> Find threads that match a regular expression.
> Usage: thread find REGEXP
> Will display thread ids whose name, target ID, or extra info matches REGEXP.
> (gdb) info threads
> Id Target Id Frame
> * 1 Thread 0x2b80 (LWP 70636) "async" main () at async.c:63
> 2 Thread 0x640 (LWP 70639) "async" futex_wait (…) at ../sysdeps/nptl/futex-internal.h:146
> 3 Thread 0x7ffff7580640 (LWP 70640) "async" futex_wait (…) at ../sysdeps/nptl/futex-internal.h:146
> (gdb) thread find 7063
> Thread 1 has target id 'Thread 0x7ffff7d82b80 (LWP 70636)'
> Thread 2 has target id 'Thread 0x7ffff7d81640 (LWP 70639)'
> (gdb) thread find async
> Thread 1 has target name 'async'
> Thread 2 has target name 'async'
> Thread 3 has target name 'async'
> (gdb) thread find async.c
> No threads match 'async.c'
>
> So the new “thread filter” command will handle “location” and “expression” filtering which is not handled by “thread find” command. Adding a new command instead of extending “thread find” will avoid changing the output of the existing command.
>
> For the new command “thread filter”, here are two options considered in handling of “expression” and “location” as in input. Output will be same for both options and only input expression and locations can be handled differently. The output is a list of “thread ids” a string type. Please refer to examples above for the usage of output from this command as other commands input. Your feedback will be greatly appreciated regarding which option would be best here:
>
> OPTION 1: Using "at" and "if" Clauses
>
> In this case for filtering, “at” and “if” clauses can be added as an optional arguments to this command which takes expression as an input for the “if” clause and location via “at” clause. The “if” clause usage is similar to similar clause in the “break” command.
>
> Command: thread filter [thread-id-list/all] [OPTION] [ at filename:linenum] [if expression]
>
> E.g.:
> (gdb) thread filter at main.cpp:3 if $_thread >1 && $_thread<5
> Filtered threads:
> $1= “2 3 4”
>
> OPTION 2: Using Convenience Variables for Location
>
> Second option is we can avoid “if” and “at” clauses and add location also to the convenience variable (e.g. $_location) then user may just filter everything via the convenience variable in the expression.
>
> Command: thread filter [thread-id-list/all] [OPTION] [expression]
>
> E.g.:
> (gdb) thread filter at main.cpp:3 if ($_thread >1 && $_thread<5 ) && $_streq($_location,”main.cpp:3”)
> Filtered threads:
> $1= “2 3 4”
> “
>
> What are your thoughts on this topic? Any feedback and new ideas are welcome for:
>
> 1. Extending "thread find" vs. New Command "thread filter"
> 2. “Option1” vs “Options2” for the new filtering command.
>
>
> Thanks & Best Regards
> Abdul Basit
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2024-10-28 13:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-02 7:24 [RFC] " Ijaz, Abdul B via Gdb
[not found] ` <PH0PR11MB7636DBD9F1AAFE6076A636D3F9432@PH0PR11MB7636.namprd11.prod.outlook.com>
2024-10-28 11:57 ` [PING][RFC] " Ijaz, Abdul B via Gdb
2024-10-28 13:41 ` Dov Grobgeld via Gdb [this message]
2024-10-28 20:10 ` Ijaz, Abdul B via Gdb
2024-10-28 14:44 ` [RFC] " Andrew Burgess via Gdb
2024-10-28 20:46 ` Ijaz, Abdul B via Gdb
2024-10-29 10:11 ` Martin Simmons
2024-10-28 21:12 ` Martin Simmons
2024-10-28 22:26 ` Ijaz, Abdul B via Gdb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA++fsGEp5Mgikup1_4Dw4ojseSnGKBQu+YZFgz6o2M=h8T7Q=w@mail.gmail.com' \
--to=gdb@sourceware.org \
--cc=abdul.b.ijaz@intel.com \
--cc=andrew.burgess@embecosm.com \
--cc=christina.schimpe@intel.com \
--cc=dov.grobgeld@gmail.com \
--cc=markus.t.metzger@intel.com \
--cc=pedro@palves.net \
--cc=simon.marchi@polymtl.ca \
--cc=tankut.baris.aktemur@intel.com \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox