From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: [PATCH 8/8] gdb: additional debug output in infrun.c and linux-nat.c
Date: Thu, 22 Jun 2023 14:17:28 +0100 [thread overview]
Message-ID: <0009534eb6886581049bb25fbed98589334368b9.1687438786.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1687438786.git.aburgess@redhat.com>
While working on some of the recent patches relating to vfork handling
I found this debug output very helpful, I'd like to propose adding
this into GDB.
With debug turned off there should be no user visible changes after
this commit.
---
gdb/infrun.c | 26 ++++++++++++++++++++++----
gdb/linux-nat.c | 23 +++++++++++++++++++----
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 3eb3b290001..52de4920661 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -435,6 +435,11 @@ show_follow_fork_mode_string (struct ui_file *file, int from_tty,
static bool
follow_fork_inferior (bool follow_child, bool detach_fork)
{
+ INFRUN_SCOPED_DEBUG_ENTER_EXIT;
+
+ infrun_debug_printf ("follow_child = %d, detach_fork = %d",
+ follow_child, detach_fork);
+
target_waitkind fork_kind = inferior_thread ()->pending_follow.kind ();
gdb_assert (fork_kind == TARGET_WAITKIND_FORKED
|| fork_kind == TARGET_WAITKIND_VFORKED);
@@ -543,6 +548,13 @@ holding the child stopped. Try \"set detach-on-fork\" or \
parent_inf->thread_waiting_for_vfork_done
= detach_fork ? inferior_thread () : nullptr;
parent_inf->pspace->breakpoints_not_allowed = detach_fork;
+
+ infrun_debug_printf
+ ("parent_inf->thread_waiting_for_vfork_done == %s",
+ (parent_inf->thread_waiting_for_vfork_done == nullptr
+ ? "nullptr"
+ : (parent_inf->thread_waiting_for_vfork_done
+ ->ptid.to_string ().c_str ())));
}
}
else
@@ -727,6 +739,8 @@ set_last_target_status_stopped (thread_info *tp)
static bool
follow_fork ()
{
+ INFRUN_SCOPED_DEBUG_ENTER_EXIT;
+
bool follow_child = (follow_fork_mode_string == follow_fork_mode_child);
bool should_resume = true;
@@ -996,6 +1010,8 @@ proceed_after_vfork_done (thread_info *thread)
static void
handle_vfork_child_exec_or_exit (int exec)
{
+ INFRUN_SCOPED_DEBUG_ENTER_EXIT;
+
struct inferior *inf = current_inferior ();
if (inf->vfork_parent)
@@ -1127,6 +1143,8 @@ handle_vfork_child_exec_or_exit (int exec)
static void
handle_vfork_done (thread_info *event_thread)
{
+ INFRUN_SCOPED_DEBUG_ENTER_EXIT;
+
/* We only care about this event if inferior::thread_waiting_for_vfork_done is
set, that is if we are waiting for a vfork child not under our control
(because we detached it) to exec or exit.
@@ -1142,8 +1160,6 @@ handle_vfork_done (thread_info *event_thread)
return;
}
- INFRUN_SCOPED_DEBUG_ENTER_EXIT;
-
/* We stopped all threads (other than the vforking thread) of the inferior in
follow_fork and kept them stopped until now. It should therefore not be
possible for another thread to have reported a vfork during that window.
@@ -3456,8 +3472,10 @@ proceed (CORE_ADDR addr, enum gdb_signal siggnal)
if (!cur_thr->control.in_infcall)
set_running (resume_target, resume_ptid, true);
- infrun_debug_printf ("addr=%s, signal=%s", paddress (gdbarch, addr),
- gdb_signal_to_symbol_string (siggnal));
+ infrun_debug_printf ("addr=%s, signal=%s, resume_ptid=%s",
+ paddress (gdbarch, addr),
+ gdb_signal_to_symbol_string (siggnal),
+ resume_ptid.to_string ().c_str ());
annotate_starting ();
diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
index 7e121b7ab41..87152621dd6 100644
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -1293,6 +1293,11 @@ get_detach_signal (struct lwp_info *lp)
static void
detach_one_lwp (struct lwp_info *lp, int *signo_p)
{
+ LINUX_NAT_SCOPED_DEBUG_ENTER_EXIT;
+
+ linux_nat_debug_printf ("lwp %s (stopped = %d)",
+ lp->ptid.to_string ().c_str (), lp->stopped);
+
int lwpid = lp->ptid.lwp ();
int signo;
@@ -1363,6 +1368,10 @@ detach_one_lwp (struct lwp_info *lp, int *signo_p)
else
signo = *signo_p;
+ linux_nat_debug_printf ("preparing to resume lwp %s (stopped = %d)",
+ lp->ptid.to_string ().c_str (),
+ lp->stopped);
+
/* Preparing to resume may try to write registers, and fail if the
lwp is zombie. If that happens, ignore the error. We'll handle
it below, when detach fails with ESRCH. */
@@ -1395,6 +1404,8 @@ detach_callback (struct lwp_info *lp)
void
linux_nat_target::detach (inferior *inf, int from_tty)
{
+ LINUX_NAT_SCOPED_DEBUG_ENTER_EXIT;
+
struct lwp_info *main_lwp;
int pid = inf->pid;
@@ -3122,13 +3133,13 @@ static ptid_t
linux_nat_wait_1 (ptid_t ptid, struct target_waitstatus *ourstatus,
target_wait_flags target_options)
{
+ LINUX_NAT_SCOPED_DEBUG_ENTER_EXIT;
+
sigset_t prev_mask;
enum resume_kind last_resume_kind;
struct lwp_info *lp;
int status;
- linux_nat_debug_printf ("enter");
-
/* The first time we get here after starting a new inferior, we may
not have added it to the LWP list yet - this is the earliest
moment at which we know its PID. */
@@ -3228,7 +3239,7 @@ linux_nat_wait_1 (ptid_t ptid, struct target_waitstatus *ourstatus,
if (target_options & TARGET_WNOHANG)
{
- linux_nat_debug_printf ("exit (ignore)");
+ linux_nat_debug_printf ("no interesting events found");
ourstatus->set_ignore ();
restore_child_signals_mask (&prev_mask);
@@ -3314,7 +3325,7 @@ linux_nat_wait_1 (ptid_t ptid, struct target_waitstatus *ourstatus,
else
*ourstatus = host_status_to_waitstatus (status);
- linux_nat_debug_printf ("exit");
+ linux_nat_debug_printf ("event found");
restore_child_signals_mask (&prev_mask);
@@ -3410,6 +3421,8 @@ ptid_t
linux_nat_target::wait (ptid_t ptid, struct target_waitstatus *ourstatus,
target_wait_flags target_options)
{
+ LINUX_NAT_SCOPED_DEBUG_ENTER_EXIT;
+
ptid_t event_ptid;
linux_nat_debug_printf ("[%s], [%s]", ptid.to_string ().c_str (),
@@ -3589,6 +3602,8 @@ linux_nat_target::kill ()
void
linux_nat_target::mourn_inferior ()
{
+ LINUX_NAT_SCOPED_DEBUG_ENTER_EXIT;
+
int pid = inferior_ptid.pid ();
purge_lwp_list (pid);
--
2.25.4
next prev parent reply other threads:[~2023-06-22 13:17 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 13:17 [PATCH 0/8] Some vfork related fixes Andrew Burgess
2023-06-22 13:17 ` [PATCH 1/8] gdb: catch more errors in gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` [PATCH 2/8] gdb: don't restart vfork parent while waiting for child to finish Andrew Burgess
2023-06-22 13:17 ` [PATCH 3/8] gdb: fix an issue with vfork in non-stop mode Andrew Burgess
2023-06-22 13:17 ` [PATCH 4/8] gdb, infrun: refactor part of `proceed` into separate function Andrew Burgess
2023-06-28 8:47 ` Aktemur, Tankut Baris
2023-07-04 15:24 ` Andrew Burgess
2023-06-22 13:17 ` [PATCH 5/8] gdb: don't resume vfork parent while child is still running Andrew Burgess
2023-06-22 13:17 ` [PATCH 6/8] gdb/testsuite: expand gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` [PATCH 7/8] gdb/testsuite: remove use of sleep from gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` Andrew Burgess [this message]
2023-07-04 15:22 ` [PATCHv2 0/8] Some vfork related fixes Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 1/8] gdb: catch more errors in gdb.base/foll-vfork.exp Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 2/8] gdb: don't restart vfork parent while waiting for child to finish Andrew Burgess
2023-07-05 10:08 ` Aktemur, Tankut Baris
2023-07-04 15:22 ` [PATCHv2 3/8] gdb: fix an issue with vfork in non-stop mode Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 4/8] gdb, infrun: refactor part of `proceed` into separate function Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 5/8] gdb: don't resume vfork parent while child is still running Andrew Burgess
2023-07-18 20:42 ` Simon Marchi
2023-07-21 9:47 ` Andrew Burgess
2023-07-23 8:53 ` Andrew Burgess
2023-08-16 14:02 ` Andrew Burgess
2023-08-17 6:36 ` Tom de Vries
2023-08-17 7:01 ` Tom de Vries
2023-08-17 8:06 ` Tom de Vries
2023-08-17 8:22 ` Tom de Vries
2023-07-04 15:22 ` [PATCHv2 6/8] gdb/testsuite: expand gdb.base/foll-vfork.exp Andrew Burgess
2023-07-05 11:22 ` Aktemur, Tankut Baris
2023-07-04 15:22 ` [PATCHv2 7/8] gdb/testsuite: remove use of sleep from gdb.base/foll-vfork.exp Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 8/8] gdb: additional debug output in infrun.c and linux-nat.c Andrew Burgess
2023-07-05 11:30 ` [PATCHv2 0/8] Some vfork related fixes Aktemur, Tankut Baris
2023-07-17 8:53 ` Andrew Burgess
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=0009534eb6886581049bb25fbed98589334368b9.1687438786.git.aburgess@redhat.com \
--to=aburgess@redhat.com \
--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).