From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 271B93858C41 for ; Wed, 8 Nov 2023 15:47:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 271B93858C41 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 271B93858C41 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699458471; cv=none; b=Gag9p4vGhMBNXpeRrX3/ZwURHDj9GcJM57dOy1xqyY3HoAaSDYk/JQwkkdcq+Jib4tFLAnmB7KDmYFz8y4N0YupVExCN6aMxhpQABOJhlvmhDrRkC1afU7avA58pOqJkhNgRNaSJwjV3CvtFd85cllFNH3tiNcWFd2L3TPWHVLM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699458471; c=relaxed/simple; bh=g2aYzJHZ196D9DHpf7Btqfjg7qc8+2BHm2tFxXro1Tg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=sZsFPfmnLHLaUw1vH/1lh2c13NXcaHMBGsgTx+bPHyUumkF6t4kcG7U1fSsb2sUaXmjHzjfIAvZxvi0urjFFH+7NsuDPoXJLyPeI6+rPAP07GrL7E7WbyFyJfBPFi4sICC5pq22uYnf8a+2s7qHOOPxk7QerYZM7ECwcQiggfEg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 3A8FleBV009544 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Nov 2023 10:47:45 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 3A8FleBV009544 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1699458465; bh=Ab9mMhTjiijm6+vvJj5bjUhXliADelWIWlu5xMtPgk0=; h=Date:Subject:To:References:From:In-Reply-To:From; b=K7frfF/1RiZvrISyNIuo2lCvPdUZJb6qR3MiFc6MLAO8nsaX/yHvPLscme2WF5q8W zHb+oWyZjMJuhpTQElud00X5nSWcOVAb7bXdYPSM+eNv4n6Ixq3Itt3SwZ6Ogl6XYx EvkZz5s/PfMJkZ8RLS+PInL2WSTuppx/AGCJECjA= Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 963381E098; Wed, 8 Nov 2023 10:47:40 -0500 (EST) Message-ID: Date: Wed, 8 Nov 2023 10:47:40 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 00/24] Fix reading and writing pseudo registers in non-current frames Content-Language: fr To: Luis Machado , gdb-patches@sourceware.org References: <20231108051222.1275306-1-simon.marchi@polymtl.ca> <9a693dcc-9213-4300-a4ee-25820bfada78@arm.com> From: Simon Marchi In-Reply-To: <9a693dcc-9213-4300-a4ee-25820bfada78@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 8 Nov 2023 15:47:40 +0000 X-Spam-Status: No, score=-3037.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > 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 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 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