Re: [PATCH 00/24] Fix reading and writing pseudo registers in non-current frames

Simon Marchi
2023-11-08T15:48:05Z

> I haven't tracked the particular patch that causes this, but for aarch64 systems supporting SVE
> (and probably SME as well) I'm seeing internal errors related to one assertion:
Thanks a lot for testing.

> Running gdb/testsuite/gdb.arch/aarch64-pseudo-unwind.exp ...
> PASS: gdb.arch/aarch64-pseudo-unwind.exp: continue to breakpoint: continue to callee
> PASS: gdb.arch/aarch64-pseudo-unwind.exp: callee, before change: p/x $v8.q.u
> PASS: gdb.arch/aarch64-pseudo-unwind.exp: callee, before change: p/x $s8.u
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: set $s8.u = 0x34353637 (GDB internal error)
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: callee, after change: p/x $v8.q.u
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: callee, after change: p/x $s8.u
> PASS: gdb.arch/aarch64-pseudo-unwind.exp: up
> PASS: gdb.arch/aarch64-pseudo-unwind.exp: caller, before change: p/x $v8.q.u
> PASS: gdb.arch/aarch64-pseudo-unwind.exp: caller, before change: p/x $s8.u
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: set $s8.u = 0x44454647 (GDB internal error)
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: caller, after change: p/x $v8.q.u
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: caller, after change: p/x $s8.u
> PASS: gdb.arch/aarch64-pseudo-unwind.exp: down
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: callee, after change in caller: p/x $v8.q.u
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: callee, after change in caller: p/x $s8.u
> PASS: gdb.arch/aarch64-pseudo-unwind.exp: continue to breakpoint: continue to break_here_c
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: p/x value
> Running gdb/testsuite/gdb.arch/aarch64-fp.exp ...
> PASS: gdb.arch/aarch64-fp.exp: set the breakpoint after setting the fp registers
> PASS: gdb.arch/aarch64-fp.exp: continue until breakpoint
> PASS: gdb.arch/aarch64-fp.exp: check register q0 value
> PASS: gdb.arch/aarch64-fp.exp: check register q1 value
> PASS: gdb.arch/aarch64-fp.exp: check register v0 value
> PASS: gdb.arch/aarch64-fp.exp: check register v1 value
> PASS: gdb.arch/aarch64-fp.exp: check register fpsr value
> PASS: gdb.arch/aarch64-fp.exp: check register fpcr value
> FAIL: gdb.arch/aarch64-fp.exp: bfloat16: set h0.bf to 129 (GDB internal error)
> FAIL: gdb.arch/aarch64-fp.exp: bfloat16: h0 fields are valid
> FAIL: gdb.arch/aarch64-fp.exp: bfloat16: set v0.h.bf[0] to 0 (GDB internal error)
> FAIL: gdb.arch/aarch64-fp.exp: bfloat16: v0.h.s[0] is 0
> FAIL: gdb.arch/aarch64-fp.exp: bfloat16: set v0.h.bf[0] to 129 (GDB internal error)
> FAIL: gdb.arch/aarch64-fp.exp: bfloat16: v0.h.s[0] is 129
>
> The failure mode is:
>
> set $s8.u = 0x34353637^M
> ../../../repos/binutils-gdb/gdb/frame.c:1441: internal-error: put_frame_register: Assertion `buf.size () == size' failed.^M
> A problem internal to GDB has been detected,^M
> further debugging may prove unreliable.^M
> ----- Backtrace -----^M
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: set $s8.u = 0x34353637 (GDB internal error)
> Resyncing due to internal error.
> 0xaaaaabd6e08f gdb_internal_backtrace_1^M
> ../../../repos/binutils-gdb/gdb/bt-utils.c:122^M
> 0xaaaaabd6e08f _Z22gdb_internal_backtracev^M
> ../../../repos/binutils-gdb/gdb/bt-utils.c:168^M
> 0xaaaaac315307 internal_vproblem^M
> ../../../repos/binutils-gdb/gdb/utils.c:396^M
> 0xaaaaac31556f _Z15internal_verrorPKciS0_St9__va_list^M
> ../../../repos/binutils-gdb/gdb/utils.c:476^M
> 0xaaaaac8604e3 _Z18internal_error_locPKciS0_z^M
> ../../../repos/binutils-gdb/gdbsupport/errors.cc:58^M
> 0xaaaaabec89c7 _Z18put_frame_register14frame_info_ptriN3gdb10array_viewIKhEE^M
> ../../../repos/binutils-gdb/gdb/frame.c:1441^M
> 0xaaaaabc55243 aarch64_pseudo_write_1^M
> ../../../repos/binutils-gdb/gdb/aarch64-tdep.c:3316^M
> 0xaaaaabc5c943 aarch64_pseudo_write^M
> ../../../repos/binutils-gdb/gdb/aarch64-tdep.c:3414^M

Ok, then I presume the regression is introduced with patch "gdb: migrate
aarch64 to new gdbarch_pseudo_register_write".

> It is also worth noting that the v registers are *not* pseudo-registers when the aarch64-fpu feature is used. If SVE
> is available though, then that means the v registers are pseudo-registers as well. You can tell them apart by their types.
>
> Real register (no SVE support):
>
> type = union aarch64v {
> vnd d;
> vns s;
> vnh h;
> vnb b;
> vnq q;
> }
>
> Pseudo-register (SVE support):
>
> union __gdb_builtin_type_vnv {
> __gdb_builtin_type_vnd d;
> __gdb_builtin_type_vns s;
> __gdb_builtin_type_vnh h;
> __gdb_builtin_type_vnb b;
> __gdb_builtin_type_vnq q;
> }

Ok, thanks for that explanation. If you recall, I asked you on IRC if
the V registers were always 16 bytes long, and you said yes. That's why
I hardcoded the size of 16 in aarch64_pseudo_write_1. But then
according to your explanation, when SVE is available, the raw register
behind S registers, for instance, is an SVE register whose length is
unknown at compile time. That's why the existing code calls
register_size to get the size of the raw register.

If you apply the patch below, does it help?

Simon

diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
index 1815d78dec40..87e6f9e10ae2 100644
--- a/gdb/aarch64-tdep.c
+++ b/gdb/aarch64-tdep.c
@@ -3300,7 +3300,7 @@ aarch64_pseudo_write_1 (gdbarch *gdbarch, frame_info_ptr next_frame,
int regnum_offset,
gdb::array_view<const gdb_byte> buf)
{
- unsigned v_regnum = AARCH64_V0_REGNUM + regnum_offset;
+ unsigned raw_regnum = AARCH64_V0_REGNUM + regnum_offset;
gdb_static_assert (AARCH64_V0_REGNUM == AARCH64_SVE_Z0_REGNUM);

/* Enough space for a full vector register.
@@ -3309,11 +3309,11 @@ aarch64_pseudo_write_1 (gdbarch *gdbarch, frame_info_ptr next_frame,
various 'scalar' pseudo registers to behavior like architectural
writes, register width bytes are written the remainder are set to
zero. */
- constexpr int raw_reg_size = 16;
- gdb_byte raw_buf[raw_reg_size] {};
+ int raw_reg_size = register_size (gdbarch, raw_regnum);
+ gdb::byte_vector raw_buf (raw_reg_size);
gdb::array_view<gdb_byte> raw_view (raw_buf);
copy (buf, raw_view.slice (0, buf.size ()));
- put_frame_register (next_frame, v_regnum, raw_view);
+ put_frame_register (next_frame, raw_regnum, raw_view);
}

/* Given REGNUM, a SME pseudo-register number, store the bytes from DATA to the