public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@efficios.com>
To: gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@efficios.com>, Pedro Alves <pedro@palves.net>
Subject: [PATCH 6/7] gdb: switch to right inferior in fetch_inferior_event
Date: Mon,  3 Apr 2023 14:52:07 -0400	[thread overview]
Message-ID: <20230403185208.197965-7-simon.marchi@efficios.com> (raw)
In-Reply-To: <20230403185208.197965-1-simon.marchi@efficios.com>

The problem explained and fixed in the previous patch could have also
been fixed by this patch.  But I think it's good change anyhow, that
could prevent future bugs, so here it is.

fetch_inferior_event switches to an arbitrary (in practice, the first) inferior
of the process target of the inferior used to fetch the event.  The idea is
that the event handling code will need to do some target calls, so we want to
switch to an inferior that has target target.

However, you can have two inferiors that share a process target, but with one
inferior having an additional target on top:

        inf 1            inf 2
        -----            -----
                         another target
        process target   process target
        exec             exec

Let's say inferior 2 is selected by do_target_wait and returns an event that is
really synthetized by "another target".  This "another target" could be a
thread or record stratum target (in the case explained by the previous patch,
it was the arch stratum target, but it's because the amd-dbgapi abuses the arch
layer).  fetch_inferior_event will then switch to the first inferior with
"process target", so inferior 1.  handle_signal_stop then tries to fetch the
thread's registers:

    ecs->event_thread->set_stop_pc
      (regcache_read_pc (get_thread_regcache (ecs->event_thread)));

This will try to get the thread's register by calling into the current target
stack, the stack of inferior 1.  This is problematic because "another target"
might have a special fetch_registers implementation.

I think it would be a good idea to switch to the inferior for which the
even was reported, not just some inferior of the same process target.
This will ensure that any target call done before we eventually call
context_switch will be done on the full target stack that reported the
event.

Not all events are associated to an inferior though.  For instance,
TARGET_WAITKIND_NO_RESUMED.  In those cases, some targets return
null_ptid, some return minus_one_ptid (ideally the expected return value
should be clearly defined / documented).  So, if the ptid returned is
either of these, switch to an arbitrary inferior with that process
target, as before.

Change-Id: I1ffc8c1095125ab591d0dc79ea40025b1d7454af
Reviewed-By: Pedro Alves <pedro@palves.net>
---
 gdb/infrun.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/gdb/infrun.c b/gdb/infrun.c
index f32e037f3649..851c01f66130 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -4358,9 +4358,13 @@ fetch_inferior_event ()
 
     gdb_assert (ecs.ws.kind () != TARGET_WAITKIND_IGNORE);
 
-    /* Switch to the target that generated the event, so we can do
-       target calls.  */
-    switch_to_target_no_thread (ecs.target);
+    /* Switch to the inferior that generated the event, so we can do
+       target calls.  If the event was not associated to a ptid,  */
+    if (ecs.ptid != null_ptid
+	&& ecs.ptid != minus_one_ptid)
+      switch_to_inferior_no_thread (find_inferior_ptid (ecs.target, ecs.ptid));
+    else
+      switch_to_target_no_thread (ecs.target);
 
     if (debug_infrun)
       print_target_wait_results (minus_one_ptid, ecs.ptid, ecs.ws);
-- 
2.40.0


  parent reply	other threads:[~2023-04-03 18:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-03 18:52 [PATCH 0/7] amdgpu: handle fork and exec Simon Marchi
2023-04-03 18:52 ` [PATCH 1/7] gdb: pass execing and following inferior to inferior_execd observers Simon Marchi
2023-04-03 18:52 ` [PATCH 2/7] gdb: add inferior_forked observable Simon Marchi
2023-04-03 18:52 ` [PATCH 3/7] gdb: remove regcache::target Simon Marchi
2023-04-03 18:52 ` [PATCH 4/7] gdb: add maybe_switch_inferior function Simon Marchi
2023-04-03 18:52 ` [PATCH 5/7] gdb: make regcache::raw_update switch to right inferior Simon Marchi
2023-04-03 18:52 ` Simon Marchi [this message]
2023-04-03 18:52 ` [PATCH 7/7] gdb/amdgpu: add follow fork and exec support Simon Marchi
2023-04-13 15:54 ` [PATCH 0/7] amdgpu: handle fork and exec Simon Marchi
2023-04-17 17:57   ` 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=20230403185208.197965-7-simon.marchi@efficios.com \
    --to=simon.marchi@efficios.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@palves.net \
    /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).