[PATCH] D79866: [CUDA][HIP] Do not emit debug info for stub function
Yaxun Liu via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed May 13 11:25:20 PDT 2020
yaxunl added a comment.
In D79866#2034460 <https://reviews.llvm.org/D79866#2034460>, @tra wrote:
> I do not see the behavior the patch is supposed to fix in CUDA.
> If I compile a simple program, host-side debugger does not see the `kernel`, sees `__device_stub_kernel` and, if the breakpoint is set on `kernel`, it treats it as a yet-to-be-loaded one and does end up breaking on intry into the kernel on the GPU side.
>
> E.g.:
>
> (cuda-gdb) info symbol kernel
> No symbol "kernel" in current context.
> (cuda-gdb) info symbol __device_stub__kernel
> __device_stub__kernel() in section .text
> (cuda-gdb) b kernel
> Function "kernel" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) y
> Breakpoint 1 (kernel) pending.
> (cuda-gdb) r
> Starting program: /usr/local/google/home/tra/work/llvm/build/debug/print
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Hello from host
> [New Thread 0x7fffdffff700 (LWP 227347)]
> [New Thread 0x7fffdf7fe700 (LWP 227348)]
> [New Thread 0x7fffdeffd700 (LWP 227349)]
> [Switching focus to CUDA kernel 0, grid 1, block (0,0,0), thread (0,0,0), device 0, sm 0, warp 0, lane 0]
>
> Thread 1 "print" hit Breakpoint 1, kernel<<<(1,1,1),(1,1,1)>>> () at print.cu:3
> 3 printf("Hello\n");
>
>
> Perhaps it's HIP-specific behavior that needs this tweak.
> For CUDA, I would rather that we continue to emit debug info for the stub (in it's __device_stub form). It is useful for debugging some issues.
can you try set bp by using file name and line number on the kernel?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D79866/new/
https://reviews.llvm.org/D79866
More information about the cfe-commits
mailing list