Fix __builtin_verbose_trap support for GPU and CPU by amd-bfilipov · Pull Request #199 · ROCm/ROCgdb

amd-bfilipov · 2026-07-10T13:23:55Z

Ticket: AIROCGDB-558

Summary

Implements complete support for __builtin_verbose_trap on both AMD GPU and CPU (x86_64), making verbose trap diagnostic messages visible in backtraces.

Problem

When __builtin_verbose_trap fired, the diagnostic inline frames were not visible in backtraces, making it impossible to see the trap category and message. Two issues prevented this:

PC pointing past trap instruction: After s_trap 2 on GPU, PC was not rewound to point at the trap instruction, causing GDB to miss the inlined DWARF frame containing the diagnostic info
Inline frames hidden by default: GDB's skip_inline_frames() intentionally hides inline frames to improve stepping experience, but this also hid the verbose trap frames

Solution

This PR provides a two-part fix:

1. PC Adjustment for s_trap 2 (GPU)

Rewind PC by 4 bytes when a wave stops with s_trap 2, similar to breakpoint handling. This ensures the PC remains in the inlined DWARF frame containing __builtin_verbose_trap debug info.

Files changed:

gdb/amd-dbgapi-target.c - PC adjustment logic
gdb/testsuite/gdb.rocm/builtin_verbose_trap.{cpp,exp} - Test coverage

2. gdbarch Hook for Inline Frame Control (GPU + CPU)

Adds architecture-specific control over inline frame visibility using GDB's gdbarch pattern. Architectures can now prevent skipping of compiler-generated inline frames containing diagnostic information.

Changes:

gdb/gdbarch_components.py - Define show_verbose_trap_inline_frame method
gdb/arch-utils.{c,h} - Default implementation (preserves current behavior)
gdb/amdgpu-tdep.c - AMD GPU implementation (checks SIGABRT + name pattern)
gdb/amd64-linux-tdep.c - CPU x86_64 implementation (checks SIGILL + name pattern)
gdb/inline-frame.c - Call gdbarch hook in skip loop
gdb/gdbarch-gen.{c,h} - Auto-generated

Detection logic:

Only shows frame when both conditions met:
1. Stop signal matches trap type (SIGABRT for GPU s_trap 2, SIGILL for CPU ud2)
2. Symbol name starts with __clang_trap_msg$<category>$<message>
Preserves normal stepping behavior (frames hidden when user steps into them)

Results

Before:

Thread 6 received signal SIGABRT, Aborted.
#0  test_trap_kernel () at test.cpp:24

After (GPU):

Thread 6 received signal SIGABRT, Aborted.
#0  __clang_trap_msg$check verbose$This is verbose trap! ()
    at test.cpp:23
#1  test_trap_kernel () at test.cpp:24

After (CPU):

Program received signal SIGILL, Illegal instruction.
#0  __clang_trap_msg$check negative$Value must be non-negative! ()
    at test.cpp:4
#1  check_value (value=-1) at test.cpp:5
#2  main () at test.cpp:12

aktemur

Please squash the second patch to the second, so that the test accompanies the fix.

lancesix · 2026-07-15T13:55:29Z

+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Test that __builtin_trap PC is correctly adjusted


The test is now using __builtin_verbose_trap, this test is about that.

lancesix

The test should exercise the stepping as well. And since you add host support, I suppose this should have a test as well.

amd-bfilipov · 2026-08-04T12:46:28Z

The test should exercise the stepping as well. And since you add host support, I suppose this should have a test as well.

Ok. Added another inline function to the test, so the test steps over it and checks whether regular inline frames stay hidden.
Added a cpu version of the test. It's in a separate commit but we can rearrange that if needed.

jhuber6 · 2026-08-05T16:53:07Z

I'm not intimately familiar with gdb, but the lldb output seems much more descriptive here. Any chance we can do something similar? From the example with -fsanitize-runtime=trap -fsanitize=undefined in Clang.

(lldb) run
Process 302532 launched: 'llvm-project/build/a.out' (x86_64)
Process 302532 stopped
* thread #1, name = 'a.out', stop reason = Undefined Behavior Sanitizer: signed integer addition overflow in 'x + 1'
       frame #1: 0x0000555555555750 a.out`signed_overflow(x=2147483647) at ubsan_test.c:4:39
   1     #include <limits.h>
   2     #include <stdio.h>
   3     
-> 4     int signed_overflow(int x) { return x + 1; }
   5     
   6     int shift_oob(int x, int amount) { return x << amount; }
   7

lancesix · 2026-08-06T16:00:58Z


 	       When dealing with a corefile, it is expected that the PC has
 	       been adjusted before generating the corefile, so no need to
 	       re-do it now.  */
-	    if ((stop_reason & AMD_DBGAPI_WAVE_STOP_REASON_BREAKPOINT) != 0
+	    if (((stop_reason & AMD_DBGAPI_WAVE_STOP_REASON_BREAKPOINT) != 0
+		|| (stop_reason & AMD_DBGAPI_WAVE_STOP_REASON_ASSERT_TRAP) != 0)


FYI, I am not sure this should be the way to go.

I have ROCm/rocm-systems#9776 to change the trap handler behaviour so this is not necessary. Such change would fix other issues reported independent to this PR.

Integrated the changes with ROCm/rocm-systems#9776 and with https://sourceware.org/pipermail/gdb-patches/2026-August/229200.html

This means that this PR only needs to show inline frames when dealing with builtin_verbose_trap.
We can now also single-step into it without hanging the program.

palves

Re. the "gdb: Add gdbarch hook to show verbose trap inline frames" patch:

The commit log needs to be turned upside down.

This adds the gdbarch hook, yes, but it needs to begin by stating what the problem is, talk about __builtin_verbose_trap, show what goes wrong today without the fix.

I.e., establish rationale for why a change is needed.

Explain that this affects both CPU and GPU.

Then state how we're fixing this. The new gdbarch hook.

lumachad · 2026-08-21T08:56:57Z

Dropping to a draft since no action in a while.

amd-bfilipov · 2026-08-31T16:43:25Z

The test should exercise the stepping as well. And since you add host support, I suppose this should have a test as well.

Added single stepping to the test.

amd-bfilipov · 2026-08-31T16:46:37Z

Re. the "gdb: Add gdbarch hook to show verbose trap inline frames" patch:

The commit log needs to be turned upside down.

This adds the gdbarch hook, yes, but it needs to begin by stating what the problem is, talk about __builtin_verbose_trap, show what goes wrong today without the fix.

I.e., establish rationale for why a change is needed.

Explain that this affects both CPU and GPU.

Then state how we're fixing this. The new gdbarch hook.

Squashed the test commit with the commit that introduces the changes, per Baris' suggestion. Dropped the PC adjust commit since Lancelots patch solves that. That leaves us with a single commit, and message for that commit has been changed according to your suggestion.

aktemur · 2026-09-01T14:29:37Z

+if {![runto test_trap_function]} {
+    return
+}


Sorry for the back and forth, but here we shall use run to breakpoint. Running to the function may not necessarily stop at the "int x = 1;" line. It may stop as "{", depending on the line table. So, we should rather define a bp at "int x = 1;" and run to it, and then do "next".

Fixed. Changed to:

runto_main

Set breakpoint at "int x = 1" line

Continue to that breakpoint

Proceed with stepping tests

This avoids ambiguity about which line in test_trap_function to stop at.

aktemur · 2026-09-01T14:30:10Z

+
+gdb_test_multiple "next" "step to trap line" {
+    -re -wrap ".*SIGILL.*" {
+	xfail "$gdb_test_name (compiler line table issue)"


Ideally we should put the bug number.

Response:
Fixed. Added comprehensive 7-line explanatory paragraph at the beginning of both test files explaining:

What the compiler line table bug is

How it manifests (trap instruction associated with wrong source line)

Why it causes the observed test behavior

How tests handle it (xfail)

The xfail now references "compiler line table bug" without a specific bug number, since the explanation paragraph
provides full context.

aktemur · 2026-09-01T14:32:13Z

+	return
+    }
+
+    gdb_test_no_output "set confirm off"


Why is this needed?

Fixed. Removed gdb_test_no_output

aktemur · 2026-09-01T14:32:55Z

+# Test single stepping to the trap line.
+# Expected: step should stop at __builtin_verbose_trap line, then
+# next step triggers the trap.
+# Due to a compiler line table issue, the trap may fire immediately.


We can remove "Due to a compiler ....". This is covered by xfail below.

Fixed. Removed inline compiler bug comment from gdb.base test (covered by explanation paragraph).

aktemur · 2026-09-01T14:33:28Z

+    # Test single stepping to the trap line.
+    # Expected: step should stop at __builtin_verbose_trap line, then
+    # next step triggers the trap.
+    # Due to a compiler line table issue, the trap may fire immediately.


We can remove "Due to a compiler...". It's covered by the xfail below.

aktemur · 2026-09-01T14:55:49Z

+both conditions indicate a verbose trap scenario.
+""",
+    type="bool",
+    name="show_verbose_trap_inline_frame",


Nit: Based on how this gdbarch method is used and implemented, it makes more sense to me to name it "is_verbose_trap_frame".

Fixed, but used Pedro's more general-purpose suggestion: renamed to should_show_inline_frame instead.

palves · 2026-09-01T14:43:57Z

+# Test that __builtin_verbose_trap inline frames are shown when trap fires.
+# __builtin_verbose_trap is a Clang-only builtin, added in Clang 17.
+
+require {expr {[test_compiler_info clang*] && ![test_compiler_info {clang-1[0-6]-*}]}}


The comment says Clang 17, and compiler check matches (though it fails to consider clang 9 and lower), but I tried this on ubuntu 24.04, which has:

$ clang -v Ubuntu clang version 18.1.3 (1ubuntu1)

And got:

$ make check RUNTESTFLAGS="CC_FOR_TARGET=clang CXX_FOR_TARGET=clang++" TESTS="gdb.base/builtin_verbose_trap.exp" ... get_compiler_info: clang-18-1-3 gdb_do_cache: get_compiler_info_1 ( c++ ) get_compiler_info: clang-18-1-3 Executing on host: clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.base/builtin_verbose_trap/builtin_verbose_trap0.o /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/builtin_verbose_trap.cpp (timeout = 300) builtin_spawn -ignore SIGHUP clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.base/builtin_verbose_trap/builtin_verbose_trap0.o /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/builtin_verbose_trap.cpp /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/builtin_verbose_trap.cpp:21:3: error: use of undeclared identifier '__builtin_verbose_trap' 21 | __builtin_verbose_trap ("check verbose", "This is verbose trap!"); | ^ 1 error generated. compiler exited with status 1 gdb compile failed, /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/builtin_verbose_trap.cpp:21:3: error: use of undeclared identifier '__builtin_verbose_trap' 21 | __builtin_verbose_trap ("check verbose", "This is verbose trap!"); | ^ 1 error generated. UNTESTED: gdb.base/builtin_verbose_trap.exp: failed to prepare testcase /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/builtin_verbose_trap.exp completed in 0 seconds === gdb Summary === # of untested testcases 1

Test fails on Clang 18 - __builtin_verbose_trap doesn't exist until Clang 19. Fixed.

palves · 2026-09-01T14:48:51Z

+# Continue to trigger the trap.
+# CPU uses ud2 instruction which generates SIGILL (not SIGABRT like GPU).
+gdb_test "continue" \
+    ".*received signal SIGILL.*" \


The leading ".*" in the regexp passed to gdb_test, and gdb_test_multiple, is unnecessary, it is implied. (Many places in the testcase have this, I won't point at them all.)

palves · 2026-09-01T15:00:06Z

+Return true if the inline frame represented by FUNC should NOT be skipped
+when stopped due to STOP_SIGNAL.  This allows architectures to show
+compiler-generated inline frames that contain verbose trap messages
+(e.g., __builtin_verbose_trap).


It seems to me that the hook's name and description is a bit more specific than necessary.

The hook is called to decide whether to skip inline frames.

The implementation should then be able to use it for verbose trap. But it could be used for other things.

We can already see a little bit of awkwardness in the semantics, because the answer to "show verbose trap inline frame?" is always "YES!".

The real question the hook is asking is "show THIS inline frame?", and then the answer is "YES, IF it's a verbose trap frame."

Fixed. Designed hook as fully general-purpose:

Hook name: should_show_inline_frame (generic, not verbose-trap-specific)

Documentation describes generic purpose: "Determine whether an inline frame should be shown to the user." Uses
verbose trap as example use case, not requirement.

Signature: (const struct symbol *func, enum gdb_signal stop_signal)

Generic parameters suitable for other scenarios

Not tied to verbose trap specifics

Default returns false (hide inline frames during stepping, existing behavior)
Architectures can override with their own visibility logic.

aktemur · 2026-09-01T15:28:49Z

Please include this at the end of the commit message:

Bug: AIROCGDB-558

amd-bfilipov · 2026-09-01T18:01:17Z

Please include this at the end of the commit message:
Bug: AIROCGDB-558

Fixed

palves · 2026-09-01T18:28:25Z

+# Test that __builtin_verbose_trap inline frames are shown when trap fires.
+# __builtin_verbose_trap is a Clang-only builtin, added in Clang 19.
+
+require {expr {[test_compiler_info clang*] && ![test_compiler_info {clang-1[0-8]-*}] && ![test_compiler_info {clang-[1-9]-*}]}}


Line too long. Break it:

require {expr {[test_compiler_info clang*] && ![test_compiler_info {clang-1[0-8]-*}] && ![test_compiler_info {clang-[1-9]-*}]}}

palves · 2026-09-01T18:51:40Z

+}
+
+# Continue to trigger the trap.
+# CPU uses ud2 instruction which generates SIGILL (not SIGABRT like GPU).


The testcase should stand alone without GPU references. And it'll be run on all kinds of CPUs, don't assume CPU == x86-64.

Also, not all CPUs will generate SIGILL. I pointed Claude at the LLVM codebase, and asked it to build me a table with what instruction __builtin_verbose_trap uses and what signal does it raise on all the supported architectures. Here's what I got:

llvm.trap lowering

Target Instruction Host signal

x86-64 / x86 ud2 SIGILL

AArch64 brk #1 SIGTRAP

ARM (A32/T32, v5T+) trap (undefined-insn class) SIGTRAP

ARM (no v5T) udf 254 SIGILL

RISC-V unimp SIGILL

PowerPC trap (tw 31,r0,r0) SIGTRAP

MIPS break SIGTRAP

SPARC ta 5 SIGTRAP

SystemZ 4-byte trap alias SIGILL

LoongArch ud 0 (alias amswap.w) SIGILL

Hexagon PS_crash pseudo —

WebAssembly unreachable (0x00) trap (no POSIX signal)

AMDGPU s_trap 2 queue error → SIGABRT

So ignoring AMD GPU, it's either SIGILL or SIGTRAP.

For SIGTRAP archs, I think we'll need to teach GDB to distinguish between the trap actually executing vs a single step or other reasons for a SIGTRAP. I'll need to think about how best to make that work.

For now, in the interest of time, I'm OK with going as is. Just tweak the testcase comment.

Fixed. Removed all architecture-specific references (ud2, x86-64, GPU, CPU) from comments in both CPU and GPU test files. Comments now use generic "trap instruction" terminology.

palves · 2026-09-01T19:26:53Z

+set has_line_table_bug 0
+
+gdb_test_multiple "disassemble /m test_trap_function" "" {
+    -re "$line_x\[^\r\n\]*\r\n(\[^\r\n\]*\r\n)*?.*ud2" {


Consider what will need to happen to the testcase when someone registers the new gdbarch for another CPU. With this approach, they'll have to come here and hardcode some other instruction.

Did you try instead to ask GDB about the line that should contain the trap, like Baris mentioned in the call earlier today? E.g., I see this:

(gdb) info line 21 Line 21 of "/home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/builtin_verbose_trap.cpp" is at address 0x55555555576d <_Z18test_trap_functionv+13> but contains no code.

The signal is "but contains no code". If the compiler put ud2 at line 21, we would not see that. That seems like a general way to test this without having to hardcode specific instructions.

Fixed. Replaced architecture-specific disassembly checks (looking for ud2/s_trap instructions) with portable info line approach in both CPU and GPU tests. Now checks for "contains no code" message to detect the compiler line table bug.

lumachad · 2026-09-02T09:29:59Z

Tests seem to be failing.

palves · 2026-09-02T10:31:19Z

+   on x86_64.  */
+
+/* Determine whether to show an inline frame.
+   Show verbose trap frames (__clang_trap_msg$...) when SIGILL occurs.  */


Two comment blocks for the same function? Did you intend to drop the first one, or something like that?

palves · 2026-09-02T10:32:52Z

  set_gdbarch_fetch_hiperr_info
    (gdbarch, amd64_linux_fetch_hiperr_info);
+
+  /* Show verbose trap inline frames when stopped due to abort.  */


"stopped due to abort"

"Abort" doesn't apply for the CPU, does it?

fixed, for cpu its "illegal instruction"

palves · 2026-09-02T10:54:09Z

@jhuber6

I'm not intimately familiar with gdb, but the lldb output seems much more descriptive here. Any chance we can do something similar? From the example with -fsanitize-runtime=trap -fsanitize=undefined in Clang.

(lldb) run
Process 302532 launched: 'llvm-project/build/a.out' (x86_64)
Process 302532 stopped
* thread #1, name = 'a.out', stop reason = Undefined Behavior Sanitizer: signed integer addition overflow in 'x + 1'
       frame #1: 0x0000555555555750 a.out`signed_overflow(x=2147483647) at ubsan_test.c:4:39
   1     #include <limits.h>
   2     #include <stdio.h>
   3     
-> 4     int signed_overflow(int x) { return x + 1; }
   5     
   6     int shift_oob(int x, int amount) { return x << amount; }
   7

Hi Joseph. I'm not familiar with "-fsanitize-runtime=trap", and a google search is finding no hits, and neither my system clang nor the one that comes with my rocm build is aware of it. Is that a new feature? I don't suppose it's the same as "-fsanitize-trap=undefined"?

Does it make the ubsan runtime use __builtin_verbose_trap? __builtin_verbose_trap takes constant strings and embeds them in the generated inline function's name (i.e., compile time), so I'm curious to see how that works.

From your output, lldb seems to be hiding frame #0 (it presents a stop at frame #1), and decoding the stop reason out of somewhere. If ubsan in that mode is really using __builtin_verbose_trap, then I guess lldb is probably extracting the arguments from the function name.

palves · 2026-09-02T11:18:57Z

I found this https://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20251117/155573.html, and the code seems to be in upstream ldlb already (in lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp).

That talks about a "-fbounds-safety" option, and I also don't have...

swiftlang/llvm-project#11645 describes it.

So does https://clang.llvm.org/docs/BoundsSafety.html, and then and https://clang.llvm.org/docs/BoundsSafetyImplPlans.html says that it's still not fully implemented.

So is this all a swift-llvm-fork-only feature? But I'm confused since you used a different command line option.

In any case, afaict from the lldb code, it is extracting the stop reason from the (runtime) argument passed to __bounds_safety_soft_trap, the magic function the ubsan runtime calls.

This is looking like should be a completely separate discussion.

palves · 2026-09-02T13:28:39Z

+	    set has_line_table_bug 1
+	    exp_continue
+	}
+	-re -wrap "" {


This is missing a "pass $gdb_test_name" call. (check the CPU version too).

__builtin_verbose_trap is a Clang builtin that allows embedding custom trap messages in the binary for better crash diagnostics. When called, it emits a trap instruction and creates an artificial inline frame with a specially-formatted name: __clang_trap_msg$<category>$<message>. Currently, when a program hits a verbose trap, GDB hides this inline frame by default (as it does for all inline frames during normal stepping). This means the trap message is not visible in backtraces, defeating the purpose of verbose traps. Before this fix, a backtrace after hitting a verbose trap shows: #0 test_trap_kernel () at test.cpp:24 After this fix: #0 __clang_trap_msg$check verbose$This is verbose trap! () at test.cpp:23 #1 test_trap_kernel () at test.cpp:24 This affects both CPU (x86_64) and GPU (AMDGPU) targets, though with different trap mechanisms: - CPU: ud2 instruction generates SIGILL - GPU: s_trap 2 instruction generates SIGABRT To fix this, add a new gdbarch hook 'should_show_inline_frame' that allows architecture-specific code to decide whether an inline frame should be shown. The hook receives the symbol and the stop signal, returning true if the frame should be displayed. The hook is implemented for: - amd64-linux: checks for SIGILL + __clang_trap_msg$ prefix - amdgpu: checks for SIGABRT + __clang_trap_msg$ prefix The signal check ensures the frame is only shown when the trap actually fires, preserving normal stepping behavior where inline frames are hidden. Bug: AIROCGDB-558

lumachad · 2026-09-02T15:01:28Z

Labelling ci:skip here as we already had a green CI. We don't need to run it again for a trivial change. Once we have code/substantial changes, let's remove the ci:skip label and let it validate fully.

Stale.

amd-bfilipov requested a review from a team as a code owner July 10, 2026 13:23

github-actions Bot assigned aktemur Jul 10, 2026

lancesix reviewed Jul 10, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/fix-s_trap-2-pc-adjustment branch 2 times, most recently from 998fd18 to f65ff67 Compare July 13, 2026 13:36

aktemur reviewed Jul 15, 2026

View reviewed changes

aktemur assigned amd-bfilipov and unassigned aktemur Jul 15, 2026

lancesix reviewed Jul 15, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/fix-s_trap-2-pc-adjustment branch from f65ff67 to 994a6fa Compare July 30, 2026 09:49

lumachad previously requested changes Jul 30, 2026

View reviewed changes

amd-bfilipov changed the title ~~Adjust PC for abort trap (s_trap 2) to improve __builtin_verbose_trap support~~ Fix __builtin_verbose_trap support for GPU and CPU Jul 30, 2026

amd-bfilipov force-pushed the users/bfilipov/fix-s_trap-2-pc-adjustment branch 2 times, most recently from c9f8030 to 60cbb93 Compare August 3, 2026 13:19

lancesix reviewed Aug 3, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/fix-s_trap-2-pc-adjustment branch 6 times, most recently from a36876d to 1b9efda Compare August 4, 2026 12:16

lancesix reviewed Aug 6, 2026

View reviewed changes

palves reviewed Aug 7, 2026

View reviewed changes

lumachad marked this pull request as draft August 21, 2026 08:57

amd-bfilipov force-pushed the users/bfilipov/fix-s_trap-2-pc-adjustment branch from 3764561 to 83763c7 Compare August 31, 2026 16:45

amd-bfilipov force-pushed the users/bfilipov/fix-s_trap-2-pc-adjustment branch 2 times, most recently from 4eee731 to 07fd530 Compare September 1, 2026 14:03

aktemur reviewed Sep 1, 2026

View reviewed changes

palves reviewed Sep 1, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/fix-s_trap-2-pc-adjustment branch 5 times, most recently from efba53e to eda2309 Compare September 1, 2026 17:57

palves reviewed Sep 1, 2026

View reviewed changes

lumachad self-requested a review September 2, 2026 09:50

amd-bfilipov force-pushed the users/bfilipov/fix-s_trap-2-pc-adjustment branch from eda2309 to 0e9bd3a Compare September 2, 2026 10:00

palves reviewed Sep 2, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/fix-s_trap-2-pc-adjustment branch from 0e9bd3a to 7572ee2 Compare September 2, 2026 10:50

amd-bfilipov force-pushed the users/bfilipov/fix-s_trap-2-pc-adjustment branch from 7572ee2 to 16a2a54 Compare September 2, 2026 12:51

palves reviewed Sep 2, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/fix-s_trap-2-pc-adjustment branch from 16a2a54 to 088f46f Compare September 2, 2026 14:58

lumachad added the ci:skip Skip all pre-commit / CI jobs while the label is up label Sep 2, 2026

palves approved these changes Sep 2, 2026

View reviewed changes

amd-bfilipov removed the ci:skip Skip all pre-commit / CI jobs while the label is up label Sep 2, 2026

amd-bfilipov merged commit 5651a23 into amd-staging Sep 2, 2026
92 of 103 checks passed

Target	Instruction	Host signal
x86-64 / x86	`ud2`	SIGILL
AArch64	`brk #1`	SIGTRAP
ARM (A32/T32, v5T+)	`trap` (undefined-insn class)	SIGTRAP
ARM (no v5T)	`udf 254`	SIGILL
RISC-V	`unimp`	SIGILL
PowerPC	`trap` (`tw 31,r0,r0`)	SIGTRAP
MIPS	`break`	SIGTRAP
SPARC	`ta 5`	SIGTRAP
SystemZ	4-byte trap alias	SIGILL
LoongArch	`ud 0` (alias `amswap.w`)	SIGILL
Hexagon	`PS_crash` pseudo	—
WebAssembly	`unreachable` (0x00)	trap (no POSIX signal)
AMDGPU	`s_trap 2`	queue error → SIGABRT

Uh oh!

Conversation

amd-bfilipov commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Problem

Solution

1. PC Adjustment for s_trap 2 (GPU)

2. gdbarch Hook for Inline Frame Control (GPU + CPU)

Results

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

aktemur left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lancesix left a comment

Choose a reason for hiding this comment

Uh oh!

amd-bfilipov commented Aug 4, 2026

Uh oh!

jhuber6 commented Aug 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

palves left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lumachad commented Aug 21, 2026

Uh oh!

amd-bfilipov commented Aug 31, 2026

Uh oh!

amd-bfilipov commented Aug 31, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amd-bfilipov commented Jul 10, 2026 •

edited

Loading

palves left a comment •

edited

Loading

palves Sep 1, 2026 •

edited

Loading