From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Carlo Bramini <carlo.bramix@libero.it>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Aarch64-SIM: BLR opcode does not support XLR register properly.
Date: Thu, 06 Feb 2020 22:59:00 -0000 [thread overview]
Message-ID: <20200206225901.GH4020@embecosm.com> (raw)
In-Reply-To: <1213380262.792613.1580923536993@mail1.libero.it>
* Carlo Bramini <carlo.bramix@libero.it> [2020-02-05 18:25:36 +0100]:
> Hello, please excuse me, I just discovered that there are multiple
> ChangeLog files and probably I have to provide an entry for the
> right one. Sorry for my mistake in previous message.
Thank you for reporting this change, and putting a patch together.
I pushed this as it is such a small change, but if you wish to
contribute further changes you will probably need to completing a
copyright assignment[1].
A copy of what I pushed is included below.
Thanks,
Andrew
[1] https://sourceware.org/gdb/wiki/ContributionChecklist#FSF_copyright_Assignment
---
commit 69b1ffdb01106ed84a41a80f6ad2d9c26c4f45a9
Author: Carlo Bramini <carlo_bramini@users.sourceforge.net>
Date: Thu Feb 6 22:50:26 2020 +0000
sim/aarch64: Fix register ordering bug in blr (PR sim/25318)
A comment in the implementation of blr says:
/* The pseudo code in the spec says we update LR before fetching.
the value from the rn. */
With 'rn' being the register holding the destination address.
This may have been true at one point, but the ISA manual now clearly
shows the destination register being read before the link register is
written.
This commit updates the implementation of blr to match.
sim/aarch64/ChangeLog:
PR sim/25318
* simulator.c (blr): Read destination register before calling
aarch64_save_LR.
Change-Id: Icb1c556064e3d9c807ac28440475caa205ab1064
diff --git a/sim/aarch64/simulator.c b/sim/aarch64/simulator.c
index 84919d6b1fc..5f16a69478c 100644
--- a/sim/aarch64/simulator.c
+++ b/sim/aarch64/simulator.c
@@ -13437,13 +13437,12 @@ br (sim_cpu *cpu)
static void
blr (sim_cpu *cpu)
{
- unsigned rn = INSTR (9, 5);
+ /* Ensure we read the destination before we write LR. */
+ uint64_t target = aarch64_get_reg_u64 (cpu, INSTR (9, 5), NO_SP);
TRACE_DECODE (cpu, "emulated at line %d", __LINE__);
- /* The pseudo code in the spec says we update LR before fetching.
- the value from the rn. */
aarch64_save_LR (cpu);
- aarch64_set_next_PC (cpu, aarch64_get_reg_u64 (cpu, rn, NO_SP));
+ aarch64_set_next_PC (cpu, target);
if (TRACE_BRANCH_P (cpu))
{
prev parent reply other threads:[~2020-02-06 22:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-05 11:21 Carlo Bramini
2020-02-05 11:39 ` Luis Machado
2020-02-05 17:14 ` Carlo Bramini
2020-02-05 17:25 ` Carlo Bramini
2020-02-06 22:59 ` Andrew Burgess [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200206225901.GH4020@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=carlo.bramix@libero.it \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox