From patchwork Mon Apr 3 18:52:07 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Marchi X-Patchwork-Id: 67228 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CCCC1385C301 for ; Mon, 3 Apr 2023 18:53:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CCCC1385C301 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1680547988; bh=1w7BOu4+GqPkNTT5AY9YwqDjwRdQPRHXaAxRnhF7CNc=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=M/tKy2V7chaDmW2nAU3pBLkCKeJ+W+5nrxZ1rTXs9R5fHu90Jo2sLFJ493UiNTtPj vokRletbhBXuVpYwvjXw8sZvL2NQ1jsKRfY9oTSIA0iucw3uqmUI+3hXA4AfRZnl/3 GwfAvONaCwNnVmJH3DSoiUPqTaZ96bLyOb/yQnms= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C85183858C27 for ; Mon, 3 Apr 2023 18:52:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C85183858C27 Received: from localhost.localdomain (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 0E29E1E226; Mon, 3 Apr 2023 14:52:21 -0400 (EDT) To: gdb-patches@sourceware.org Cc: Simon Marchi , Pedro Alves Subject: [PATCH 6/7] gdb: switch to right inferior in fetch_inferior_event Date: Mon, 3 Apr 2023 14:52:07 -0400 Message-Id: <20230403185208.197965-7-simon.marchi@efficios.com> X-Mailer: git-send-email 2.40.0 In-Reply-To: <20230403185208.197965-1-simon.marchi@efficios.com> References: <20230403185208.197965-1-simon.marchi@efficios.com> MIME-Version: 1.0 X-Spam-Status: No, score=-1173.4 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_SOFTFAIL, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Simon Marchi via Gdb-patches From: Simon Marchi Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" 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 --- 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);