[RFC] New command "thread filter" in GDB

[RFC] New command "thread filter" in GDB

[Ijaz, Abdul B via 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

[PING][RFC] New command "thread filter" in GDB

[Ijaz, Abdul B via Gdb]

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

Re: [PING][RFC] New command "thread filter" in GDB

[Dov Grobgeld via Gdb]

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

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

[Ijaz, Abdul B via Gdb]

Thanks Grobgeld for your feedback.

> I guess such functionality could be implemented by your predicate() function.

This new command should be able to filter from all threads using expression and location (file or line).  So, would be useful for any threads related command.

Best Regards
Abdul Basit

-----Original Message-----
From: Dov Grobgeld <dov.grobgeld@gmail.com> 
Sent: Monday, October 28, 2024 2:42 PM
To: Ijaz, Abdul B <abdul.b.ijaz@intel.com>
Cc: 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; Andrew Burgess <andrew.burgess@embecosm.com>; simon.marchi@polymtl.ca; tom@tromey.com
Subject: Re: [PING][RFC] New command "thread filter" in GDB

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

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

[Andrew Burgess via 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

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

[Ijaz, Abdul B via Gdb]

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

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

[Martin Simmons]

I think option#2 is more flexible because it allows for boolean
expressions on the location, in particular using || for "or" which might
be useful.

__Martin


>>>>> On Mon, 28 Oct 2024 20:46:11 +0000, Ijaz, Abdul B via Gdb said:
> 
> 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
> 

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

[Martin Simmons]

>>>>> On Wed, 2 Oct 2024 07:24:21 +0000, Ijaz, Abdul B via Gdb said:
> 
> 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”

Are you also proposing an extension to "info threads" and "threads
apply"?  Otherwise, I don't see how a script can use the result of
"thread filter" in those commands.

Maybe some extension to allow a string type list from a variable like in
the following (currently, you get an error "History value must have
integer type.")?

info threads $1
thread apply $1 p workitem

__Martin

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

[Ijaz, Abdul B via Gdb]

Thanks Martin for the feedback.

>>   *   info threads 1 2 3 4
>>      *   “info thread” command print thread info for thread ids “1 2 3 4 5”

Martin > Are you also proposing an extension to "info threads" and "threads apply"?  Otherwise, I don't see how a script can use the result of "thread filter" in those commands.
Maybe some extension to allow a string type list from a variable like in the following (currently, you get an error "History value must have integer type.")?

Abdul > The output of this command can still be used by only copying the value inside the quotes and discarding the double quotes for "info threads" or "thread apply" commands in current gdb.  But, yes eventually, "info threads" and "thread apply" command will be extended to use the output of this command from history value.  This is the reason that the output of this command is proposed a space separated list of ids a string value and added to history to make it more useable. E.g.

"
thread filter all $_thread<5
Filtered threads:
$1 = “1 2 3 4”

$ info threads 1 2 3 4

"

Thanks & Best Regards
Abdul Basit

-----Original Message-----
From: Martin Simmons <qqxnjvamvxwx@dyxyl.com> 
Sent: Monday, October 28, 2024 10:12 PM
To: Ijaz, Abdul B <abdul.b.ijaz@intel.com>
Cc: 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>
Subject: Re: [RFC] New command "thread filter" in GDB

>>>>> On Wed, 2 Oct 2024 07:24:21 +0000, Ijaz, Abdul B via Gdb said:
> 
> 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”

Are you also proposing an extension to "info threads" and "threads apply"?  Otherwise, I don't see how a script can use the result of "thread filter" in those commands.

Maybe some extension to allow a string type list from a variable like in the following (currently, you get an error "History value must have integer type.")?

info threads $1
thread apply $1 p workitem

__Martin
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