From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id IKqDNP07rV+fTAAAWB0awg (envelope-from ) for ; Thu, 12 Nov 2020 08:43:25 -0500 Received: by simark.ca (Postfix, from userid 112) id D4A181F08B; Thu, 12 Nov 2020 08:43:25 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 7AC6A1E58E for ; Thu, 12 Nov 2020 08:43:25 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EB33A384A00F; Thu, 12 Nov 2020 13:43:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EB33A384A00F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1605188605; bh=ahzDc956UufxF1DA12B8HYLnVH9UCXa0oTpxtge1j8o=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=wjwArkIy3qqyOiyJJ5LwIUpE3E67jAXhGoueMp0/cqxkIDttnMaZtZPeDsaazZRuf JAazi8f1mtlGfeguiRX5SWi6XgWLhWpitcEtnYgLtAfoM8xWqfopkYkEyfsZaCe+DQ WO+skjBXeJYFhHJME3MYTOGxFb+Z3QTZ1ElSL0Hs= Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by sourceware.org (Postfix) with ESMTPS id 603D73858006 for ; Thu, 12 Nov 2020 13:43:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 603D73858006 Received: by mail-ej1-x644.google.com with SMTP id w13so7711795eju.13 for ; Thu, 12 Nov 2020 05:43:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ahzDc956UufxF1DA12B8HYLnVH9UCXa0oTpxtge1j8o=; b=eElAorPib7aABtJDjUv1xh6+VsV2M+h7n7rFSrv8XXQUvy0Xgb+lmM7QD6GYHnhOpl CYyxvcvNjVZHp/RrOGfjMxZJMzCUnmbB4nVMRJ9pGaQpr3qEThcJB3qGot+vI93oaktM sBk4TntZMg0Q7GDyKD/hekC3qqKKOxa8AyxQVdPOzPtxtxln0k8GiharPfltUiCFkoeu ouOrxkYNoD1RsWKsXEW0ZydlYvEu9bF0OZLfArMHKhoVb3+SDJlNsV6pa0AcIsJK4ugT dMy73LDJMFY2pEdI8/rxdkRZMfy70SEl8a3kMr8prBDShuHBI7g0pWo+Omlv54V8GCwe 69jg== X-Gm-Message-State: AOAM533wJhNlm7v2jt1Z8L8piKLmV8ri9Vl3i9X/WDX098t56jgkeHFe 04ilnVXjqo5jdS5qXAnqjeHRBvm0EUF9PA== X-Google-Smtp-Source: ABdhPJwbugqlB8w9N5dk+3gzOhJZReb0t761Qm3xSk9INr2HWb1Yrfl/VayiBu327M5XwwLuCutKQQ== X-Received: by 2002:a17:906:8401:: with SMTP id n1mr29668360ejx.215.1605188601091; Thu, 12 Nov 2020 05:43:21 -0800 (PST) Received: from atlantis.home ([2a03:1b20:3:f011::6d]) by smtp.gmail.com with ESMTPSA id n7sm2382251edb.34.2020.11.12.05.43.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2020 05:43:19 -0800 (PST) To: gdb-patches@sourceware.org Subject: [PATCH] arc: Write correct "eret" value during register collection Date: Thu, 12 Nov 2020 14:43:10 +0100 Message-Id: <20201112134310.8544-1-shahab.vahedi@gmail.com> X-Mailer: git-send-email 2.29.2 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: Shahab Vahedi via Gdb-patches Reply-To: Shahab Vahedi Cc: Shahab Vahedi , Shahab Vahedi , Francois Bedard Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" From: Shahab Vahedi In collect_register() function of arc-linux-tdep.c, the "eret" (exception return) register value was not being reported correctly. This patch fixes that. Background: When asked for the "pc" value, we have to update the "eret" register with GDB's STOP_PC. The "eret" instructs the kernel code where to jump back when an instruction has stopped due to a breakpoint. This is how collect_register() was doing so: --------------8<-------------- if (regnum == gdbarch_pc_regnum (gdbarch)) regnum = ARC_ERET_REGNUM; regcache->raw_collect (regnum, buf + arc_linux_core_reg_offsets[regnum]); -------------->8-------------- Root cause: Although this is using the correct offset (ERET register's), it is also changing the REGNUM itself. Therefore, raw_collect (regnum, ...) is not reading from "pc" anymore. gdb/ChangeLog: * arc-linux-tdep.c (collect_register): Use "eret" value while still writing to "pc" register cache. --- gdb/arc-linux-tdep.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/gdb/arc-linux-tdep.c b/gdb/arc-linux-tdep.c index 9ff5f1214a1..3530c7cbdd8 100644 --- a/gdb/arc-linux-tdep.c +++ b/gdb/arc-linux-tdep.c @@ -319,9 +319,13 @@ static void collect_register (const struct regcache *regcache, struct gdbarch *gdbarch, int regnum, gdb_byte *buf) { + int offset; + /* Skip non-existing registers. */ - if ((arc_linux_core_reg_offsets[regnum] == ARC_OFFSET_NO_REGISTER)) + if (arc_linux_core_reg_offsets[regnum] == ARC_OFFSET_NO_REGISTER) return; + else + offset = arc_linux_core_reg_offsets[ARC_ERET_REGNUM]; /* The address where the execution has stopped is in pseudo-register STOP_PC. However, when kernel code is returning from the exception, @@ -332,8 +336,8 @@ collect_register (const struct regcache *regcache, struct gdbarch *gdbarch, the program will continue at the address after the current instruction. */ if (regnum == gdbarch_pc_regnum (gdbarch)) - regnum = ARC_ERET_REGNUM; - regcache->raw_collect (regnum, buf + arc_linux_core_reg_offsets[regnum]); + offset = arc_linux_core_reg_offsets[ARC_ERET_REGNUM]; + regcache->raw_collect (regnum, buf + offset); } void -- 2.29.2