From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id LEc6LQOQv2COZAAAWB0awg (envelope-from ) for ; Tue, 08 Jun 2021 11:42:59 -0400 Received: by simark.ca (Postfix, from userid 112) id A74101F163; Tue, 8 Jun 2021 11:42:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 BF8A71E01F for ; Tue, 8 Jun 2021 11:42:58 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 74FF9395BC4F for ; Tue, 8 Jun 2021 15:42:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 74FF9395BC4F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1623166978; bh=s3rQWDHnPYoSSftyWlMWAro76l4esY/6HoAK3f3oB1I=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=Q2gkvXxN6RSxwpzUrp3O/nhPktyW2wAcK4+hPGko55pbmUNbQPCF0bd5vqqMBTs/5 GZqfRfMGyw7Ji4OcWjzom8QK9dIAxrUb4rpQ2gJ1azLo9CB5L64jwkKzqx1TPRylMk oz73/1jkZ9Z0HRAXI8erzqGZVdpZRxWp9bIOWUr8= Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by sourceware.org (Postfix) with ESMTPS id 2BF88383B408 for ; Tue, 8 Jun 2021 15:42:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2BF88383B408 Received: by mail-qk1-x730.google.com with SMTP id c124so20593258qkd.8 for ; Tue, 08 Jun 2021 08:42:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=s3rQWDHnPYoSSftyWlMWAro76l4esY/6HoAK3f3oB1I=; b=e82hRI4KXuAxi73taf6ojsFaGE6QDYZQLbiju/yqDFaV/RUQK199Lu7MG4yYpkR/x1 6MPtuxoM7A9DVkSeStwhuKd/bhQnpgJKw43ssvxYuDkfZyIeYjTSZTlXvY2GQ8wLd3D1 DVcy4iqWylGbarbLzkt6nB0945LVp9bfexUzAF35NhocVwuJlPo5QILlCfkIGJWSBppT PWsdkh4uMGZkFYmiHgbx/yUtGIy3LiZnwEghoee3SYs7dtGA4bBWxbe2suY8UdPYn7CZ c+1oF6WfxsQoGn6+M06sLVepWw2xLvabmYlwwlhr+3gU3uuOjsjF/P6diy1MzzS7z4K7 4Fyw== X-Gm-Message-State: AOAM531/JB9P4IP18oD6xY+pVC/TeBzv8K/1OWvV5t7c2o73ADgkvqb6 TfyluiuHhWNGLBs5GAsEaIFB41tnfjhyDw== X-Google-Smtp-Source: ABdhPJzTt+CkHikQfrVqm3/k5ZFzOtTTGTPubAZ7IYmKz+BbaAmFWz/AA9Td8hXUXILGoi0SXiJiww== X-Received: by 2002:a37:62d6:: with SMTP id w205mr15477182qkb.194.1623166958703; Tue, 08 Jun 2021 08:42:38 -0700 (PDT) Received: from localhost.localdomain ([2804:7f0:4841:5c9d:15d:c71d:53e:bed3]) by smtp.gmail.com with ESMTPSA id t201sm6894845qka.49.2021.06.08.08.42.37 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Jun 2021 08:42:38 -0700 (PDT) To: gdb-patches@sourceware.org Subject: [PATCH] Fix displaced stepping watchpoint check order Date: Tue, 8 Jun 2021 12:42:30 -0300 Message-Id: <20210608154230.354202-1-luis.machado@linaro.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 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: , From: Luis Machado via Gdb-patches Reply-To: Luis Machado Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" When checking the stopped data address, I noticed, under some circumstances, that the instruction at PC wasn't the expected one. This happens because the displaced stepping machinery restores the buffer before checking if the instruction executed successfully, which in turn calls the watchpoint check. I guess this was never noticed because stopped data address checks usually don't need to fetch the instruction at PC, but AArch64 needs to do it from now on. We should check if the instruction executed successfully before we restore the scratchpad contents. Regression tested on aarch64-linux/Ubuntu 20.04. gdb/ChangeLog: YYYY-MM-DD Luis Machado * displaced-stepping.c (displaced_step_buffers::finish): Move check upwards. --- gdb/displaced-stepping.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c index 59b78c22f6a..06324d523d8 100644 --- a/gdb/displaced-stepping.c +++ b/gdb/displaced-stepping.c @@ -227,6 +227,11 @@ displaced_step_buffers::finish (gdbarch *arch, thread_info *thread, ULONGEST len = gdbarch_max_insn_length (arch); + /* Check if the execution was successful before restoring the buffer + contents. */ + bool instruction_executed_successfully + = displaced_step_instruction_executed_successfully (arch, sig); + /* Restore memory of the buffer. */ write_memory_ptid (thread->ptid, buffer->addr, buffer->saved_copy.data (), len); @@ -237,9 +242,6 @@ displaced_step_buffers::finish (gdbarch *arch, thread_info *thread, regcache *rc = get_thread_regcache (thread); - bool instruction_executed_successfully - = displaced_step_instruction_executed_successfully (arch, sig); - if (instruction_executed_successfully) { gdbarch_displaced_step_fixup (arch, copy_insn_closure.get (), -- 2.25.1