RE: [RFC] New command "thread filter" in GDB

["Ijaz, Abdul B via Gdb" <gdb@sourceware.org>]

Thanks Andrew for you feedback.

Andrew>Having the current location available via convenience variables sounds useful regardless, though I'd be tempted to suggest it should be split into two, file and line.

Abdul > Sure, we can have two convenience variables separately for file and line. It would be easier to use them separately in any expression also. So, regarding Option#2 then two new convenience variables for thread file and line location information will be added in any case, instead of one common location convenience variable.

Andrew>The other possibility, which you don't specifically mention would be using GDB's option system, rather than going with a more natural language syntax (OPTION #1).  You could allow something like:
  (gdb) thread filter [-location LOC]
                      [-thread-id LIST]
                      [expression]

Abdul> Right, Option#1 can be implemented using GDB' options instead of "if" and "at" clauses.  Main motivation for Option#1 was the existing breakpoint command and also to be able to share command options with existing thread apply command. But agree using GDB's option system would be better for Option#1. Only in this suggestion, I would like to keep "-thread-list" handing like Option#1 or #2 to have the handling of it similar to the existing "thread apply" command instead of having a separate argument for it . This argument can be a mandatory like "thread apply" command which is either list of thread ids or "all" option to use command for all threads.

So, lets call it Option#3 to be clear where GDB's options are used instead of "if" and "at" clauses.  It would be great if you may confirm that command looks fine to you without [-thread-id LIST].  Also it will be really helpful and nice if anyone has any opinion regarding this option or other options mentioned in original email. This will be the new command then using this option:

(gdb) thread filter all/LIST [-location LOC]
                      [expression]

Thanks & Best Regards
Abdul Basit

-----Original Message-----
From: Andrew Burgess <aburgess@redhat.com> 
Sent: Monday, October 28, 2024 3:44 PM
To: Ijaz, Abdul B <abdul.b.ijaz@intel.com>; gdb@sourceware.org
Cc: Aktemur, Tankut Baris <tankut.baris.aktemur@intel.com>; Schimpe, Christina <christina.schimpe@intel.com>; Metzger, Markus T <markus.t.metzger@intel.com>
Subject: Re: [RFC] New command "thread filter" in GDB

"Ijaz, Abdul B via Gdb" <gdb@sourceware.org> writes:

> 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.

Having the current location available via convenience variables sounds useful regardless, though I'd be tempted to suggest it should be split into two, file and line.

The other possibility, which you don't specifically mention would be using GDB's option system, rather than going with a more natural language syntax (OPTION #1).  You could allow something like:

  (gdb) thread filter [-location LOC]
                      [-thread-id LIST]
                      [expression]

with the expression being: everything left on the command line once the arguments have been parsed.

I'm not sure if this is better or not, but you hadn't mentioned this possibility, so I thought I'd offer it up.

Thanks,
Andrew



>
> 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

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