Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Lancelot SIX <lancelot.six@amd.com>
To: <gdb-patches@sourceware.org>
Cc: <tankutbaris.aktemur@amd.com>, <Luis.Machado@amd.com>,
	Lancelot SIX <lancelot.six@amd.com>
Subject: [PATCH] gdb/testsuite: Fix gdb.rocm/displaced-stepping.exp
Date: Wed, 21 Oct 2026 14:39:16 +0100	[thread overview]
Message-ID: <20261021133916.123674-1-lancelot.six@amd.com> (raw)

The gdb.rocm/displaced-stepping.exp testcase currently fails with:

  with debug displaced on -- stepi
  Unhandled dwarf expression opcode 0xe9
  (gdb) FAIL: gdb.rocm/displaced-stepping.exp: with debug displaced on -- stepi

This is because when doing the stepi, GDB computes the current frame ID
in set_step_info.  This will go and evaluate the CFA for the current
frame, which reads AMDGPU debug info, which is not supported by GDB
currently.

Current AMDGPU DWARF requires changes expected to be available in the
future DWARF-6 standard (address space support), as well as llvm private
opcodes (DW_OP_LLVM_user DW_OP_LLVM_form_aspace_address):

    $ llvm-dwarfdump --debug-frame displaced-stepping.0.hip-amdgcn-amd-amdhsa--gfx1031
    [...]
    00000014 00000018 00000018 FDE cie=00000000 pc=00001a00...00001b64
      Format:       DWARF32
      DW_CFA_def_cfa_expression: DW_OP_lit0, DW_OP_lit6, DW_OP_LLVM_user DW_OP_LLVM_form_aspace_address

At this point, there is no way to support this in GDB, so instead this
patch proposes to fix the failure by instructing the compiler to not
produce any unwind table.

Tested on x86_64-linux + AMDGPU-gfx1031.

Change-Id: I2e62270f39c9e96324ae01d401bafb46cfff596c
---
 gdb/testsuite/gdb.rocm/displaced-stepping.exp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.rocm/displaced-stepping.exp b/gdb/testsuite/gdb.rocm/displaced-stepping.exp
index 2466a678f19..a72c19e5314 100644
--- a/gdb/testsuite/gdb.rocm/displaced-stepping.exp
+++ b/gdb/testsuite/gdb.rocm/displaced-stepping.exp
@@ -23,7 +23,8 @@ require allow_hip_tests
 
 # Since GDB doesn't yet understand DWARF expressions generated by the HIP
 # compiler, purposefully generate the binary without debug info.
-if {[build_executable "failed to prepare" $testfile $srcfile {hip}]} {
+if {[build_executable "failed to prepare" $testfile $srcfile \
+	{hip "additional_flags=-fno-unwind-tables -fno-asynchronous-unwind-tables"}]} {
     return
 }
 

base-commit: cfd8ea4e101d9793895d9b8b016da5c2ec6a672a
-- 
2.43.0


             reply	other threads:[~2026-10-21 13:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 13:39 Lancelot SIX [this message]
2026-10-21 14:21 ` Simon Marchi
2026-10-21 14:23   ` Six, Lancelot
2026-10-21 14:22 ` Aktemur, Baris

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=20261021133916.123674-1-lancelot.six@amd.com \
    --to=lancelot.six@amd.com \
    --cc=Luis.Machado@amd.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tankutbaris.aktemur@amd.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