From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MMxlDLdttmCtYwAAWB0awg (envelope-from ) for ; Tue, 01 Jun 2021 13:26:15 -0400 Received: by simark.ca (Postfix, from userid 112) id 30C791F163; Tue, 1 Jun 2021 13:26:15 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (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 ESMTPS id D89E61E54D for ; Tue, 1 Jun 2021 13:26:14 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 817113954C14 for ; Tue, 1 Jun 2021 17:26:14 +0000 (GMT) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id 1D932395443B for ; Tue, 1 Jun 2021 17:25:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1D932395443B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 49CAE782A6; Tue, 1 Jun 2021 17:25:26 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FvfF21Kjqz3sQR; Tue, 1 Jun 2021 17:25:26 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id C5AEC2BFFE; Tue, 1 Jun 2021 17:25:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Simon Marchi , gdb-patches@sourceware.org References: <20210531161558.10600-1-jhb@FreeBSD.org> <35b34a01-3790-d3dd-cacc-2f6320e8d2c5@polymtl.ca> From: John Baldwin Subject: Re: [PATCH] Conditionally restore displaced stepping state after fork. Message-ID: Date: Tue, 1 Jun 2021 10:25:22 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <35b34a01-3790-d3dd-cacc-2f6320e8d2c5@polymtl.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 5/31/21 5:59 PM, Simon Marchi wrote: > On 2021-05-31 12:15 p.m., John Baldwin wrote: >> There is no default method for >> gdbarch_displaced_step_restore_all_in_ptid, so calling it >> unconditionally for fork events triggered an assertion failure on >> platforms that do not support displaced stepping. To fix, only invoke >> the method if the gdbarch supports displaced stepping. >> >> gdb/ChangeLog: >> >> * infrun.c (handle_inferior_event): Only call >> gdbarch_displaced_step_restore_all_in_ptid if >> gdbarch_supports_displaced_stepping is true. >> --- >> gdb/ChangeLog | 6 ++++++ >> gdb/infrun.c | 3 ++- >> 2 files changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/gdb/ChangeLog b/gdb/ChangeLog >> index 03910c0634..b0f448a35e 100644 >> --- a/gdb/ChangeLog >> +++ b/gdb/ChangeLog >> @@ -1,3 +1,9 @@ >> +2021-05-30 John Baldwin >> + >> + * infrun.c (handle_inferior_event): Only call >> + gdbarch_displaced_step_restore_all_in_ptid if >> + gdbarch_supports_displaced_stepping is true. >> + >> 2021-05-27 Simon Marchi >> >> * Fix tab after space indentation issues throughout. >> diff --git a/gdb/infrun.c b/gdb/infrun.c >> index e9624d2a9b..6fd077796f 100644 >> --- a/gdb/infrun.c >> +++ b/gdb/infrun.c >> @@ -5496,7 +5496,8 @@ handle_inferior_event (struct execution_control_state *ecs) >> /* If this is a fork (child gets its own address space copy) and some >> displaced step buffers were in use at the time of the fork, restore >> the displaced step buffer bytes in the child process. */ >> - if (ecs->ws.kind == TARGET_WAITKIND_FORKED) >> + if (ecs->ws.kind == TARGET_WAITKIND_FORKED >> + && gdbarch_supports_displaced_stepping (gdbarch)) >> gdbarch_displaced_step_restore_all_in_ptid >> (gdbarch, parent_inf, ecs->ws.value.related_pid); > > gdbarch_supports_displaced_stepping checks whether the gdbarch implement > gdbarch_displaced_step_prepare. But a gdbarch could technically > implement gdbarch_displaced_step_prepare and not > gdbarch_displaced_step_restore_all_in_ptid. Would it be useful though? > If not, we force that arches implementing gdbarch_displaced_step_prepare > also implement gdbarch_displaced_step_restore_all_in_ptid by using a > post-check on gdbarch creation (like we check that if an arch implements > gdbarch_displaced_step_prepare, it also implements > gdbarch_displaced_step_finish). In that case, checking > gdbarch_supports_displaced_stepping here will be sufficient. > > If there's a case for having gdbarch_displaced_step_prepare but not > gdbarch_displaced_step_restore_all_in_ptid, then we would probably need > to use gdbarch_displaced_step_restore_all_in_ptid_p. But I don't see a > use case for that, so I'd go with the other solution. I should have been clearer that I wasn't fully sure this was the right fix. I had read the comment for gdbarch_supports_displaced_stepping as meaning it only checked the one method as a check for the group. /* Return true if the gdbarch implements the required methods to use displaced stepping. */ static bool gdbarch_supports_displaced_stepping (gdbarch *arch) { /* Only check for the presence of step_copy_insn. Other required methods are checked by the gdbarch validation. */ return gdbarch_displaced_step_copy_insn_p (arch); } If I'm understanding you correctly, we don't currently enforce a check for this particular method in gdbarch validation so I need to add that? -- John Baldwin