From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id m1sJMlBDyl/3MwAAWB0awg (envelope-from ) for ; Fri, 04 Dec 2020 09:10:24 -0500 Received: by simark.ca (Postfix, from userid 112) id BFE351F0AB; Fri, 4 Dec 2020 09:10:24 -0500 (EST) 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, URIBL_BLOCKED autolearn=ham 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 38C221E58D for ; Fri, 4 Dec 2020 09:10:21 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B73DD386F448; Fri, 4 Dec 2020 14:10:20 +0000 (GMT) Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTP id 709E2386186E for ; Fri, 4 Dec 2020 14:10:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 709E2386186E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=brobecker@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 44CB2562E5; Fri, 4 Dec 2020 09:10:18 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZWUTzw00tood; Fri, 4 Dec 2020 09:10:18 -0500 (EST) Received: from float.home (localhost.localdomain [127.0.0.1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id C54575616F; Fri, 4 Dec 2020 09:10:17 -0500 (EST) Received: by float.home (Postfix, from userid 1000) id D1F17A1880; Fri, 4 Dec 2020 18:10:12 +0400 (+04) Date: Fri, 4 Dec 2020 18:10:12 +0400 From: Joel Brobecker To: Shahab Vahedi via Gdb-patches Subject: Re: [PUSHED gdb-10-branch] arc: Write correct "eret" value during register collection Message-ID: <20201204141012.GA151412@adacore.com> References: <20201112134310.8544-1-shahab.vahedi@gmail.com> <20201204105714.12903-1-shahab.vahedi@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201204105714.12903-1-shahab.vahedi@gmail.com> 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: , Cc: Shahab Vahedi , Shahab Vahedi , Tom Tromey , Francois Bedard Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hello Shahab, > 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. > > v2: > - Fix a copy/paste issue as rightfully addressed by Tom [1]. > > [1] > https://sourceware.org/pipermail/gdb-patches/2020-November/173208.html > > gdb/ChangeLog: > > * arc-linux-tdep.c (collect_register): Populate "eret" by > "pc" value from the regcache when asked for "pc" value. Once the first release off a branch is made (GDB 10.1 in this case), we ask that all changes pushed to the branch for the corrective release have a PR attached to the change, with details of the problem being solved. This is because we use the PRs to create a list of the fixes that were made in the corrective release, and the PRs are a link to more information for those who might be interested in them. Would you mind doing the following please? - Create a PR for it? For the description of the problem, I think the commit message above is fine. But if you have additional information you can share, please do so ;-). - Set the PR's target milestone to GDB 10.2. - Once you have the PR created, please add a note to the PR indicating the commits that were pushed to both master and the gdb-10-branch, just keep have an easy track record of which commits solved that PR. Typically, I would post something like this: This PR was solved on master with this commit: | commit 10c19fadfd45da5262d2f8b9624be71c274ff15d | Author: Shahab Vahedi | Date: Thu Nov 12 12:50:33 2020 +0100 | Subject: arc: Write correct "eret" value during register collection The patch above was also pushed to gdb-10-branch as: | commit abaf3df98b69d66c779ff0896d66fea9cbb67481 | Author: Shahab Vahedi | Date: Thu Nov 12 12:50:33 2020 +0100 | Subject: arc: Write correct "eret" value during register collection - Update the ChangeLog entry on both master and gdb-10-branch to include the PR number. E.g. | 2020-11-29 Hannes Domani | !!! -> | PR tui/26973 | * tui/tui-layout.c (tui_apply_current_layout): Don't delete the | static locator win info. - Once the above is done, I believe you can close the PR as RESOVED/FIXED. Thank you! -- Joel