From: "Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>
To: Simon Marchi <simark@simark.ca>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH v2 3/3] gdb, multi-target: pass a target argument to delete_exited_threads
Date: Tue, 21 Apr 2026 07:48:57 +0000 [thread overview]
Message-ID: <DM4PR11MB7303A0662E681DF97488F5CDC42C2@DM4PR11MB7303.namprd11.prod.outlook.com> (raw)
In-Reply-To: <fa334f9c-10bd-4ebd-9865-1c1b20e0bb6a@simark.ca>
On Monday, April 20, 2026 7:21 PM, Simon Marchi wrote:
> On 4/20/26 9:46 AM, Tankut Baris Aktemur wrote:
> > diff --git a/gdb/inferior.c b/gdb/inferior.c
> > index e050dec402e..1481f46cdd1 100644
> > --- a/gdb/inferior.c
> > +++ b/gdb/inferior.c
> > @@ -368,7 +368,7 @@ inferior_appeared (struct inferior *inf, int pid)
> > {
> > /* If this is the first inferior with threads, reset the global
> > thread id. */
> > - delete_exited_threads ();
> > + delete_exited_threads (nullptr);
>
> Not related to your patch, but I'm a bit curious to know why this
> delete_exited_threads is not done when we "mourn" the previous existence
> of the inferior. In the lifecycle of an inferior, there should always
> be a point where an inferior stops "being", before "becoming" a new
> execution. At that point, the process target would be known and we
> could pass it to delete_exited_threads.
Hmm, was it maybe desired to keep the threads around at mourn phase even
in exited state for some user-interface related reason? I'm not sure.
> > @@ -2112,7 +2112,7 @@ thread_select (const char *tidstr, thread_info *tp)
> >
> > /* Since the current thread may have changed, see if there is any
> > exited thread we can now delete. */
> > - delete_exited_threads ();
> > + delete_exited_threads (nullptr);
>
> I don't know if it's worthwhile, but we could restrict this one to the
> process target of the previously selected thread.
I'm inclined towards preserving the current behavior for this one.
The previous thread and the selected thread can both be from the
same target and both could be exited, meaning they could potentially
be deleted by the call. If a behavior change is desired, IMHO it
deserves a separate patch -- the behavioral changes in other places
in this series were clear optimizations but the change here would be
more than that, I think.
> Approved-By: Simon Marchi <simon.marchi@efficios.com>
>
> Simon
Thank you.
-Baris
Intel Deutschland GmbH
Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2026-04-21 7:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 13:46 [PATCH v2 1/3] gdb: parameterize all_threads_safe for the target and ptid Tankut Baris Aktemur
2026-04-20 13:46 ` [PATCH v2 2/3] gdb, multi-target: pass a target argument to prune_threads Tankut Baris Aktemur
2026-04-20 17:02 ` Simon Marchi
2026-04-20 13:46 ` [PATCH v2 3/3] gdb, multi-target: pass a target argument to delete_exited_threads Tankut Baris Aktemur
2026-04-20 17:20 ` Simon Marchi
2026-04-21 7:48 ` Aktemur, Tankut Baris [this message]
2026-04-20 16:58 ` [PATCH v2 1/3] gdb: parameterize all_threads_safe for the target and ptid Simon Marchi
2026-04-20 17:21 ` Aktemur, Tankut Baris
2026-04-20 17:49 ` Simon Marchi
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=DM4PR11MB7303A0662E681DF97488F5CDC42C2@DM4PR11MB7303.namprd11.prod.outlook.com \
--to=tankut.baris.aktemur@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
/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