[PATCH] gdb/testsuite: Fix gdb.rocm/displaced-stepping.exp

[PATCH] gdb/testsuite: Fix gdb.rocm/displaced-stepping.exp

[Lancelot SIX]

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

Re: [PATCH] gdb/testsuite: Fix gdb.rocm/displaced-stepping.exp

[Simon Marchi]

On 10/21/26 9:39 AM, Lancelot SIX wrote:
> 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

I suppose something changed in the compiler since the test was merged,
since it used to pass.  Did it not emit those tables before?

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Simon

RE: [PATCH] gdb/testsuite: Fix gdb.rocm/displaced-stepping.exp

[Aktemur, Baris]

AMD General

On Wednesday, October 21, 2026 3:39 PM, Six, Lancelot wrote:
> 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"}]} {

Looks good to me.  I tested on gfx1201.  Maybe worth noting that "nodebug" does not
suffice.

-Baris

Reviewed-By: Tankut Baris Aktemur <TankutBaris.Aktemur@amd.com>

RE: [PATCH] gdb/testsuite: Fix gdb.rocm/displaced-stepping.exp

[Six, Lancelot]

AMD General

> -----Original Message-----
> From: Simon Marchi <simark@simark.ca>
> Sent: 21 October 2026 15:22
> To: Six, Lancelot <Lancelot.Six@amd.com>; gdb-patches@sourceware.org
> Cc: Aktemur, Baris <TankutBaris.Aktemur@amd.com>; Machado, Luis
> <Luis.Machado@amd.com>
> Subject: Re: [PATCH] gdb/testsuite: Fix gdb.rocm/displaced-stepping.exp
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 10/21/26 9:39 AM, Lancelot SIX wrote:
> > 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
>
> I suppose something changed in the compiler since the test was merged,
> since it used to pass.  Did it not emit those tables before?
>

Indeed.  I have not tracked when the compiler started to emit those by default. As you say, this used to pass.

Thanks for the review.

> Approved-By: Simon Marchi <simon.marchi@efficios.com>
>
> Simon