All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helge Deller <deller@kernel.org>
To: qemu-devel@nongnu.org
Cc: "Matt Turner" <mattst88@gmail.com>,
	"Helge Deller" <deller@gmx.de>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Laurent Vivier" <laurent@vivier.eu>,
	"Pierrick Bouvier" <pierrick.bouvier@oss.qualcomm.com>
Subject: [PULL 3/6] linux-user/mips64: fix mipsn32 elf_core_copy_regs entry width
Date: Sun, 24 May 2026 15:19:05 +0200	[thread overview]
Message-ID: <20260524131909.162990-4-deller@kernel.org> (raw)
In-Reply-To: <20260524131909.162990-1-deller@kernel.org>

From: Matt Turner <mattst88@gmail.com>

For mipsn32 (TARGET_ABI32=y, TARGET_LONG_BITS=64):
  abi_ulong = uint32_t (4 bytes) — for pointers and ABI-sized fields
  target_ulong = uint64_t (8 bytes) — for general-purpose registers

linux-user/elfload.c allocates target_elf_prstatus using the
mips64/target_elf.h definition where target_elf_gregset_t has
target_ulong reserved[45] (8 bytes each, 360 bytes total).

However, in linux-user/mips64/elfload.c, #include "target_elf.h" inside
the included mips/elfload.c resolves to mips/target_elf.h (compiler
searches the file's own directory first), where the union uses abi_ulong
reserved[45].  For mipsn32 this gives 4-byte entries (180 bytes), not
the 8-byte entries (360 bytes) that elfload.c actually allocated.

Writing via r->reserved[34] therefore lands at byte offset 34*4=136
instead of the correct 34*8=272, silently zeroing the EPC in the core
file.

Fix by casting the pointer to target_ulong * so writes always use 8-byte
slots and land at the offsets matching the allocated layout.

This does not change behavior for mips64 (N64) where abi_ulong already
equals target_ulong (both 8 bytes).

Signed-off-by: Matt Turner <mattst88@gmail.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Helge Deller <deller@gmx.de>
---
 linux-user/mips64/elfload.c | 35 +++++++++++++++++++++++++----------
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/linux-user/mips64/elfload.c b/linux-user/mips64/elfload.c
index 9081ae8111..e4d84a7bd6 100644
--- a/linux-user/mips64/elfload.c
+++ b/linux-user/mips64/elfload.c
@@ -15,16 +15,31 @@
  */
 void elf_core_copy_regs(target_elf_gregset_t *r, const CPUMIPSState *env)
 {
-    /* R0 is always 0; r->reserved is zero-initialised by the caller */
+    /*
+     * linux-user/elfload.c allocates target_elf_prstatus using the
+     * definition from mips64/target_elf.h, where target_elf_gregset_t
+     * has target_ulong reserved[45] (8 bytes each = 360 bytes total).
+     *
+     * But in this compilation unit, "#include target_elf.h" resolved to
+     * mips/target_elf.h (wrong directory), so our local target_elf_gregset_t
+     * has abi_ulong reserved[45] which is only 4 bytes each for mipsn32.
+     * Using r->reserved[i] would write to the wrong offsets for mipsn32.
+     *
+     * Cast to target_ulong * to always write 8-byte entries at the correct
+     * positions, matching the layout that elfload.c allocated.
+     */
+    target_ulong *regs = (target_ulong *)r;
+
+    /* R0 is always 0; buffer is zero-initialised by the caller */
     for (int i = 1; i < 32; i++) {
-        r->reserved[i] = tswap64(env->active_tc.gpr[i]);
+        regs[i] = tswap64(env->active_tc.gpr[i]);
     }
-    r->reserved[26] = 0;   /* k0 */
-    r->reserved[27] = 0;   /* k1 */
-    r->reserved[32] = tswap64(env->active_tc.LO[0]);
-    r->reserved[33] = tswap64(env->active_tc.HI[0]);
-    r->reserved[34] = tswap64(env->active_tc.PC);
-    r->reserved[35] = tswap64(env->CP0_BadVAddr);
-    r->reserved[36] = tswap64(env->CP0_Status);
-    r->reserved[37] = tswap64(env->CP0_Cause);
+    regs[26] = 0;   /* k0 */
+    regs[27] = 0;   /* k1 */
+    regs[32] = tswap64(env->active_tc.LO[0]);
+    regs[33] = tswap64(env->active_tc.HI[0]);
+    regs[34] = tswap64(env->active_tc.PC);
+    regs[35] = tswap64(env->CP0_BadVAddr);
+    regs[36] = tswap64(env->CP0_Status);
+    regs[37] = tswap64(env->CP0_Cause);
 }
-- 
2.54.0



  parent reply	other threads:[~2026-05-24 13:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-24 13:19 [PULL 0/6] Linux user next patches Helge Deller
2026-05-24 13:19 ` [PULL 1/6] linux-user/hppa: add coredump support Helge Deller
2026-05-24 13:19 ` [PULL 2/6] linux-user/mips64: fix elf_core_copy_regs register layout in core files Helge Deller
2026-05-24 13:19 ` Helge Deller [this message]
2026-05-24 13:19 ` [PULL 4/6] linux-user/mips: use tswap32 in elf_core_copy_regs Helge Deller
2026-05-24 13:19 ` [PULL 5/6] linux-user/riscv: add coredump support Helge Deller
2026-05-24 13:19 ` [PULL 6/6] linux-user/sh4: add VDSO support for sh4 and sh4eb Helge Deller
2026-05-26 14:59 ` [PULL 0/6] Linux user next patches Stefan Hajnoczi

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=20260524131909.162990-4-deller@kernel.org \
    --to=deller@kernel.org \
    --cc=deller@gmx.de \
    --cc=laurent@vivier.eu \
    --cc=mattst88@gmail.com \
    --cc=philmd@linaro.org \
    --cc=pierrick.bouvier@oss.qualcomm.com \
    --cc=qemu-devel@nongnu.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 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.