All of lore.kernel.org
 help / color / mirror / Atom feed
From: heavenlydev <heavenlydev01@gmail.com>
To: Palmer Dabbelt <palmer@dabbelt.com>,
	Alistair Francis <alistair.francis@wdc.com>
Cc: Weiwei Li <liwei1518@gmail.com>,
	Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>,
	Liu Zhiwei <zhiwei_liu@linux.alibaba.com>,
	Chao Liu <chao.liu@processmission.com>,
	qemu-riscv@nongnu.org, qemu-devel@nongnu.org,
	Enrique Abma Romero <heavenlydev01@gmail.com>
Subject: [PATCH] target/riscv/gdbstub.c: use misa_mxl_max for GPR write width
Date: Sat,  8 Aug 2026 14:15:11 +0200	[thread overview]
Message-ID: <20260808121511.18088-1-heavenlydev01@gmail.com> (raw)

From: Enrique Abma Romero <heavenlydev01@gmail.com>

riscv_cpu_gdb_write_register() decides whether to sign-truncate an
incoming GPR value to 32 bits based on env->xl, the hart current XLEN.
This is asymmetric with the rest of the gdbstub: both the read path
(riscv_cpu_gdb_read_register) and the target description size registers
off misa_mxl_max, the maximum XLEN. GDB therefore always exchanges
8-byte register fields for an RV64-max hart, but a write is truncated to
its low 32 bits whenever the hart happens to be executing in an RV32
privilege context (env->xl == MXL_RV32, e.g. S/U-mode with SXL/UXL
narrowed to 32). The upper 32 bits are silently dropped, so a debugger
cannot set the full 64-bit architectural register even though the CPU
state and the read path are 64-bit.

Key the write width off misa_mxl_max, matching the read path and the
advertised register size, so a full-width write is honored regardless of
the hart current privilege XLEN.

Signed-off-by: Enrique Abma Romero <heavenlydev01@gmail.com>
---
 target/riscv/gdbstub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/riscv/gdbstub.c b/target/riscv/gdbstub.c
index 9abbf5b..9284579 100644
--- a/target/riscv/gdbstub.c
+++ b/target/riscv/gdbstub.c
@@ -89,7 +89,7 @@ int riscv_cpu_gdb_write_register(CPUState *cs, uint8_t *mem_buf, int n)
     const size_t regsize = mcc->def->misa_mxl_max == MXL_RV32 ? 4 : 8;
     uint64_t tmp = ldn(env, mem_buf, regsize);
 
-    if (env->xl < MXL_RV64) {
+    if (mcc->def->misa_mxl_max < MXL_RV64) {
         tmp = (int32_t)tmp;
     }
 
-- 
2.39.5



             reply	other threads:[~2026-08-08 13:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-08 12:15 heavenlydev [this message]
2026-08-10 14:30 ` [PATCH] target/riscv/gdbstub.c: use misa_mxl_max for GPR write width Richard Henderson

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=20260808121511.18088-1-heavenlydev01@gmail.com \
    --to=heavenlydev01@gmail.com \
    --cc=alistair.francis@wdc.com \
    --cc=chao.liu@processmission.com \
    --cc=daniel.barboza@oss.qualcomm.com \
    --cc=liwei1518@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=zhiwei_liu@linux.alibaba.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.