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 14:34:47 -0500 [thread overview]
Message-ID: <25f0e95c-32bb-41d1-acd0-69273ab7c88b@polymtl.ca> (raw)
In-Reply-To: <ea729a56-b255-45e2-adf0-a0d36bca01f5@arm.com>
On 11/8/23 12:08, Luis Machado wrote:
> On 11/8/23 15:47, Simon Marchi wrote:
>>> 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
>
> Right. The V registers are always 16 bytes long, being real or pseudo-registers. So
> their sizes are fixed.
>
> The other pseudo-registers are also fixed size. What chages is the size of the SVE
> register the V/Q/D/S/H/B pseudo-registers map to.
>
>> 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?
>
> It gets rid of the internal error due to the assertion, but I still see FAIL's due to wrong
> values being printed.
>
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: callee, after change: p/x $v8.q.u
> 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
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: callee, after change in caller: p/x $v8.q.u
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: continue to breakpoint: continue to break_here_c
> FAIL: gdb.arch/aarch64-pseudo-unwind.exp: p/x value
> FAIL: gdb.arch/aarch64-fp.exp: bfloat16: h0 fields are valid
>
> p/x $v8.q.u
> $3 = {0xaaab34353637}
> (gdb) FAIL: gdb.arch/aarch64-pseudo-unwind.exp: callee, after change: p/x $v8.q.u
> --
> p/x $v8.q.u
> $7 = {0xaaab34353637}
> (gdb) FAIL: gdb.arch/aarch64-pseudo-unwind.exp: caller, after change: p/x $v8.q.u
> --
> p/x $s8.u
> $8 = 0x34353637
> (gdb) FAIL: gdb.arch/aarch64-pseudo-unwind.exp: caller, after change: p/x $s8.u
> --
> p/x $v8.q.u
> $9 = {0xaaab34353637}
> (gdb) FAIL: gdb.arch/aarch64-pseudo-unwind.exp: callee, after change in caller: p/x $v8.q.u
> --
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000aaab0fad6e60 in ?? ()
> (gdb) FAIL: gdb.arch/aarch64-pseudo-unwind.exp: continue to breakpoint: continue to break_here_c
> p/x value
> No symbol "value" in current context.
> (gdb) FAIL: gdb.arch/aarch64-pseudo-unwind.exp: p/x value
> testcase binutils-gdb/gdb/testsuite/gdb.arch/aarch64-pseudo-unwind.exp completed in 1 seconds
> Running binutils-gdb/gdb/testsuite/gdb.arch/aarch64-fp.exp ...
> --
> p $h0
> $7 = {bf = 1.136e-28, f = 0.00061798, u = 4368, s = 4368}
> (gdb) FAIL: gdb.arch/aarch64-fp.exp: bfloat16: h0 fields are valid
Ah, damn, probably because I switched to byte_vector, which doesn't do
the zero-initialization we want to do. Here's a new patch (that applies
on the series directly) that doesn't use byte_vector.
diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
index 1815d78dec4..200e740e013 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;
+ int raw_reg_size = register_size (gdbarch, raw_regnum);
gdb_byte raw_buf[raw_reg_size] {};
- gdb::array_view<gdb_byte> raw_view (raw_buf);
+ gdb::array_view<gdb_byte> raw_view (raw_buf, raw_reg_size);
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
Simon
next prev parent reply other threads:[~2023-11-08 19:34 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
2023-11-08 17:08 ` Luis Machado
2023-11-08 19:34 ` Simon Marchi [this message]
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=25f0e95c-32bb-41d1-acd0-69273ab7c88b@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).