Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>,
	gdb-patches@sourceware.org
Subject: Re: [PATCH v7 5/5] gdb/infrun: handle already-exited threads when attempting to stop
Date: Thu, 14 May 2020 12:25:49 +0100	[thread overview]
Message-ID: <4e9a3338-528e-2e3f-294b-561a8556acf7@redhat.com> (raw)
In-Reply-To: <f71767c2-81f6-542f-4123-0c1cbfdacdf8@redhat.com>

On 5/13/20 10:15 PM, Pedro Alves via Gdb-patches wrote:

> After giving it some thought and experimentation, I think we should
> go back to your idea of not deleting the last thread of the process.

There's one point that I forgot to mention about the benefit of this
approach, which I should mention for the archives.

The current use case we're handling deals with the update_thread_list
call from within stop_all_threads.

However, update_thread_list calls can happen at any point while the
inferior is running.  Say, in non-stop mode or async background mode, and
the user types "info threads".  At that point, an inferior may have exited,
and GDB finds no threads for the process, before the inferior exit event
is seen.  If that happens, then the user is not able to switch to that
inferior any longer in order to collect the process exit.  The solution in
v8 handles this scenario too, while the "don't delete if pending event"
solution only handled the stop_all_threads scenario.

Thanks,
Pedro Alves



      parent reply	other threads:[~2020-05-14 11:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1587563226.git.tankut.baris.aktemur@intel.com>
2020-04-22 15:00 ` [PATCH v7 3/5] gdb/remote: do not delete a thread if it has a pending exit event Tankut Baris Aktemur
2020-05-04 14:43   ` Pedro Alves
2020-05-04 15:33     ` Aktemur, Tankut Baris
2020-05-13 14:20       ` Pedro Alves
2020-04-22 15:00 ` [PATCH v7 5/5] gdb/infrun: handle already-exited threads when attempting to stop Tankut Baris Aktemur
2020-04-22 16:07   ` Aktemur, Tankut Baris
2020-05-03 15:38   ` Aktemur, Tankut Baris
2020-05-13 21:15   ` Pedro Alves
2020-05-14  8:50     ` Aktemur, Tankut Baris
2020-05-14 11:32       ` Pedro Alves
2020-05-14 11:42         ` Aktemur, Tankut Baris
2020-05-14 11:25     ` Pedro Alves [this message]

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=4e9a3338-528e-2e3f-294b-561a8556acf7@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tankut.baris.aktemur@intel.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