Branch: refs/heads/bbiiggppiigg/handle_s_trap
Home: https://github.com/dyninst/dyninst
Commit: 4f279978b35198edb0fb301a1d46d6b74bcecf57
https://github.com/dyninst/dyninst/commit/4f279978b35198edb0fb301a1d46d6b74bcecf57
Author: wuxx1279 <bbiiggppiigg@xxxxxxxxx>
Date: 2026-06-19 (Fri, 19 Jun 2026)
Changed paths:
M parseAPI/src/IA_amdgpu.C
M parseAPI/src/IA_amdgpu.h
Log Message:
-----------
[parseAPI] Treat AMDGPU s_trap 0x02 (llvm.trap) as a block terminator
s_trap was decoded as an ordinary scalar instruction with no control-flow
category, so parseAPI gave it an implicit fall-through and kept parsing the
bytes after it. For non-returning traps (s_trap 0x02, the lowering of
llvm.trap) the following bytes are padding/garbage, leading to mis-parses.
Override IA_amdgpu::isSoftwareException() to recognize s_trap and inspect its
trap ID (low 8 bits of the SIMM16 immediate). Only trap ID 0x02 terminates the
wavefront, so only it is reported as a software exception, which makes the
parser end the block with no fall-through edge. Trap IDs 0x01 (debugger
breakpoint) and 0x03 (llvm.debugtrap) resume execution, so they keep their
fall-through; all other (reserved) trap IDs are left unchanged.
The trap-ID semantics follow the LLVM AMDGPU trap handler ABI:
https://llvm.org/docs/AMDGPUUsage.html#trap-handler-abi
The distinction depends on the immediate operand, so it cannot be expressed in
the opcode-only entryToCategory()/allowsFallThrough() paths and is handled in
the AMDGPU parse adapter instead.
Co-Authored-By: Claude Opus 4.8 <noreply@xxxxxxxxxxxxx>
To unsubscribe from these emails, change your notification settings at https://github.com/dyninst/dyninst/settings/notifications
|