From: Simon Marchi <simon.marchi@polymtl.ca>
To: Luis Machado <luis.machado@arm.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 00/24] Fix reading and writing pseudo registers in non-current frames
Date: Wed, 8 Nov 2023 10:47:40 -0500 [thread overview]
Message-ID: <b67d697e-b8ad-4061-ab8e-4448466994df@polymtl.ca> (raw)
In-Reply-To: <9a693dcc-9213-4300-a4ee-25820bfada78@arm.com>
> 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
next prev parent reply other threads:[~2023-11-08 15:47 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 5:00 Simon Marchi
2023-11-08 5:00 ` [PATCH 01/24] gdb: don't handle i386 k registers as pseudo registers Simon Marchi
2023-11-11 19:29 ` John Baldwin
2023-11-08 5:00 ` [PATCH 02/24] gdb: use reg_buffer_common throughout gdbsupport/common-regcache.h Simon Marchi
2023-11-11 19:42 ` John Baldwin
2023-11-08 5:00 ` [PATCH 03/24] gdb: make store_integer take an array_view Simon Marchi
2023-11-08 5:00 ` [PATCH 04/24] gdb: simplify conditions in regcache::{read,write,raw_collect,raw_supply}_part Simon Marchi
2023-11-08 5:00 ` [PATCH 05/24] gdb: change regcache interface to use array_view Simon Marchi
2023-11-13 13:43 ` Andrew Burgess
2023-11-13 14:00 ` Andrew Burgess
2023-11-13 16:47 ` Simon Marchi
2023-11-08 5:00 ` [PATCH 06/24] gdb: fix bugs in {get,put}_frame_register_bytes Simon Marchi
2023-11-13 15:00 ` Andrew Burgess
2023-11-13 19:51 ` Simon Marchi
2023-11-08 5:00 ` [PATCH 07/24] gdb: make put_frame_register take an array_view Simon Marchi
2023-11-08 5:00 ` [PATCH 08/24] gdb: change value_of_register and value_of_register_lazy to take the next frame Simon Marchi
2023-11-08 5:00 ` [PATCH 09/24] gdb: remove frame_register Simon Marchi
2023-11-08 5:00 ` [PATCH 10/24] gdb: make put_frame_register take the next frame Simon Marchi
2023-11-08 5:00 ` [PATCH 11/24] gdb: make put_frame_register_bytes " Simon Marchi
2023-11-08 5:00 ` [PATCH 12/24] gdb: make get_frame_register_bytes " Simon Marchi
2023-11-08 5:00 ` [PATCH 13/24] gdb: add value::allocate_register Simon Marchi
2023-11-08 5:00 ` [PATCH 14/24] gdb: read pseudo register through frame Simon Marchi
2023-11-11 20:11 ` John Baldwin
2023-11-08 5:00 ` [PATCH 15/24] gdb: change parameter name in frame_unwind_register_unsigned declaration Simon Marchi
2023-11-08 5:01 ` [PATCH 16/24] gdb: rename gdbarch_pseudo_register_write to gdbarch_deprecated_pseudo_register_write Simon Marchi
2023-11-14 12:12 ` Andrew Burgess
2023-11-14 15:16 ` Simon Marchi
2023-11-08 5:01 ` [PATCH 17/24] gdb: add gdbarch_pseudo_register_write that takes a frame Simon Marchi
2023-11-14 12:20 ` Andrew Burgess
2023-11-14 15:20 ` Simon Marchi
2023-11-08 5:01 ` [PATCH 18/24] gdb: migrate i386 and amd64 to the new gdbarch_pseudo_register_write Simon Marchi
2023-11-11 20:16 ` John Baldwin
2023-11-13 2:59 ` Simon Marchi
2023-11-08 5:01 ` [PATCH 19/24] gdb: make aarch64_za_offsets_from_regnum return za_offsets Simon Marchi
2023-11-08 5:01 ` [PATCH 20/24] gdb: add missing raw register read in aarch64_sme_pseudo_register_write Simon Marchi
2023-11-08 5:01 ` [PATCH 21/24] gdb: migrate aarch64 to new gdbarch_pseudo_register_write Simon Marchi
2023-11-08 5:01 ` [PATCH 22/24] gdb: migrate arm to gdbarch_pseudo_register_read_value Simon Marchi
2023-11-08 5:01 ` [PATCH 23/24] gdb: migrate arm to new gdbarch_pseudo_register_write Simon Marchi
2023-11-08 5:01 ` [PATCH 24/24] gdb/testsuite: add tests for unwinding of pseudo registers Simon Marchi
2023-11-08 5:16 ` [PATCH 00/24] Fix reading and writing pseudo registers in non-current frames Simon Marchi
2023-11-09 3:05 ` Simon Marchi
2023-11-08 11:57 ` Luis Machado
2023-11-08 15:47 ` Simon Marchi [this message]
2023-11-08 17:08 ` Luis Machado
2023-11-08 19:34 ` Simon Marchi
2023-11-09 19:04 ` Simon Marchi
2023-11-13 13:10 ` Luis Machado
2023-11-13 15:08 ` Luis Machado
2023-11-11 20:26 ` John Baldwin
2023-11-13 3:03 ` Simon Marchi
2023-12-01 16:27 Simon Marchi
2023-12-01 16:56 ` Simon Marchi
2023-12-14 14:51 ` Luis Machado
2023-12-14 16:20 ` Simon Marchi
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=b67d697e-b8ad-4061-ab8e-4448466994df@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).