From: Pedro Alves <pedro@palves.net>
To: gdb-patches@sourceware.org
Subject: [PATCH 05/11] gdbserver: Reorganize linux_process_target::filter_event
Date: Thu, 3 Mar 2022 14:40:14 +0000 [thread overview]
Message-ID: <20220303144020.3601082-6-pedro@palves.net> (raw)
In-Reply-To: <20220303144020.3601082-1-pedro@palves.net>
Reorganize linux-low.cc:linux_process_target::filter_event such that
all the handling for events for LWPs not in the LWP list is together.
This helps make a following patch clearer. The comments and debug
messages have also been tweaked to have them synchronized with the GDB
counterpart.
Change-Id: If9019635f63a846607cfda44b454b4254a404019
---
gdbserver/linux-low.cc | 76 ++++++++++++++++++++++--------------------
1 file changed, 40 insertions(+), 36 deletions(-)
diff --git a/gdbserver/linux-low.cc b/gdbserver/linux-low.cc
index e7c01420ae3..2d14a0254c7 100644
--- a/gdbserver/linux-low.cc
+++ b/gdbserver/linux-low.cc
@@ -2148,46 +2148,50 @@ linux_process_target::filter_event (int lwpid, int wstat)
child = find_lwp_pid (ptid_t (lwpid));
- /* Check for stop events reported by a process we didn't already
- know about - anything not already in our LWP list.
-
- If we're expecting to receive stopped processes after
- fork, vfork, and clone events, then we'll just add the
- new one to our list and go back to waiting for the event
- to be reported - the stopped process might be returned
- from waitpid before or after the event is.
-
- But note the case of a non-leader thread exec'ing after the
- leader having exited, and gone from our lists (because
- check_zombie_leaders deleted it). The non-leader thread
- changes its tid to the tgid. */
-
- if (WIFSTOPPED (wstat) && child == NULL && WSTOPSIG (wstat) == SIGTRAP
- && linux_ptrace_get_extended_event (wstat) == PTRACE_EVENT_EXEC)
+ /* Check for events reported by anything not in our LWP list. */
+ if (child == nullptr)
{
- ptid_t child_ptid;
-
- /* A multi-thread exec after we had seen the leader exiting. */
- threads_debug_printf ("Re-adding thread group leader LWP %d after exec.",
- lwpid);
+ if (WIFSTOPPED (wstat))
+ {
+ if (WSTOPSIG (wstat) == SIGTRAP
+ && linux_ptrace_get_extended_event (wstat) == PTRACE_EVENT_EXEC)
+ {
+ /* A non-leader thread exec'ed after we've seen the
+ leader zombie, and removed it from our lists (in
+ check_zombie_leaders). The non-leader thread changes
+ its tid to the tgid. */
+ threads_debug_printf
+ ("Re-adding thread group leader LWP %d after exec.",
+ lwpid);
- child_ptid = ptid_t (lwpid, lwpid);
- child = add_lwp (child_ptid);
- child->stopped = 1;
- switch_to_thread (child->thread);
- }
+ child = add_lwp (ptid_t (lwpid, lwpid));
+ child->stopped = 1;
+ switch_to_thread (child->thread);
+ }
+ else
+ {
+ /* A process we are controlling has forked and the new
+ child's stop was reported to us by the kernel. Save
+ its PID and go back to waiting for the fork event to
+ be reported - the stopped process might be returned
+ from waitpid before or after the fork event is. */
+ threads_debug_printf
+ ("Saving LWP %d status %s in stopped_pids list",
+ lwpid, status_to_str (wstat).c_str ());
+ add_to_pid_list (&stopped_pids, lwpid, wstat);
+ }
+ }
+ else
+ {
+ /* Don't report an event for the exit of an LWP not in our
+ list, i.e. not part of any inferior we're debugging.
+ This can happen if we detach from a program we originally
+ forked and then it exits. */
+ }
- /* If we didn't find a process, one of two things presumably happened:
- - A process we started and then detached from has exited. Ignore it.
- - A process we are controlling has forked and the new child's stop
- was reported to us by the kernel. Save its PID. */
- if (child == NULL && WIFSTOPPED (wstat))
- {
- add_to_pid_list (&stopped_pids, lwpid, wstat);
- return;
+ if (child == nullptr)
+ return;
}
- else if (child == NULL)
- return;
thread = get_lwp_thread (child);
--
2.26.2
next prev parent reply other threads:[~2022-03-03 14:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-03 14:40 [PATCH 00/11] Linux: Fix issues around thread group leader exits Pedro Alves
2022-03-03 14:40 ` [PATCH 01/11] Fix gdbserver/linux target_waitstatus logging assert Pedro Alves
2022-03-03 14:40 ` [PATCH 02/11] Fix gdb.threads/clone-new-thread-event.exp race Pedro Alves
2022-03-03 14:40 ` [PATCH 03/11] Fix gdb.threads/current-lwp-dead.exp race Pedro Alves
2022-03-03 14:40 ` [PATCH 04/11] gdb: Reorganize linux_nat_filter_event Pedro Alves
2022-03-03 14:40 ` Pedro Alves [this message]
2022-03-03 14:40 ` [PATCH 06/11] gdbserver: Reindent check_zombie_leaders Pedro Alves
2022-03-03 14:40 ` [PATCH 07/11] Re-add zombie leader on exit, gdb/linux Pedro Alves
2022-03-07 20:08 ` Simon Marchi
2022-03-07 20:27 ` Pedro Alves
2022-03-07 20:31 ` Simon Marchi
2022-03-09 14:37 ` Pedro Alves
2022-03-03 14:40 ` [PATCH 08/11] Re-add zombie leader on exit, gdbserver/linux Pedro Alves
2022-03-03 14:40 ` [PATCH 09/11] Ensure EXIT is last event, gdb/linux Pedro Alves
2022-03-07 20:24 ` Simon Marchi
2022-03-09 0:21 ` Lancelot SIX
2022-03-09 14:45 ` Pedro Alves
2022-03-09 22:29 ` Lancelot SIX
2022-03-10 11:46 ` Pedro Alves
2022-03-03 14:40 ` [PATCH 10/11] Ensure EXIT is last event, gdbserver/linux Pedro Alves
2022-03-03 14:40 ` [PATCH 11/11] Process exit status is leader exit status testcase Pedro Alves
2023-06-22 11:28 ` Ilya Leoshkevich
2023-06-22 13:07 ` Tom de Vries
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=20220303144020.3601082-6-pedro@palves.net \
--to=pedro@palves.net \
--cc=gdb-patches@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).