Summary
When a user compiles a kernel via cuda.core.Program with debug=True or lineinfo=True, cuda-gdb cannot show source lines because the program name= defaults to the literal string "default_program" and no file with that name exists on disk. The debugger reports default_program:10 — No such file or directory and users lose source-level debugging.
This is tracked in NVBugs 6420444 (originally reported by Linaro). The customer was unblocked by a workaround: pass a real file path as name= and write the source there manually. We want this to work by default.
Proposed fix
When debug=True or lineinfo=True is set on Program(...):
- Derive a meaningful filename from the caller's Python frame + a sanitized kernel identifier (e.g.
train_py__matmul.cu).
- Materialize the NVRTC source to a temp file at that path.
- Pass that real path as NVRTC's
name=.
- Clean up the temp file on program destruction.
When neither debug flag is set, behavior is unchanged (no disk I/O, same label as today).
Impact on existing users
- No API or signature changes.
- Users who already pass
name= explicitly: zero change (their value wins).
- Users who don't request debug info: zero change (no temp file written).
- Users who do request debug info: the label in
cuda-gdb / traces / logs changes from default_program to a real path. Cosmetic; easily searchable.
Edge cases to handle
- Read-only
/tmp or sandboxed environments: fall back to today's label-only behavior on write failure, do not crash.
- Concurrent compiles of the same-named kernel: use unique suffix (
tempfile.mkstemp or PID+hash).
- Respect
TMPDIR; user-only permissions on the temp file.
- Cleanup on both normal destruction and process exit.
Acceptance criteria
cuda-gdb shows source lines when stepping into a kernel compiled with debug=True, without any user-side workaround.
- Existing behavior preserved when debug flags are off.
- Graceful fallback when the filesystem isn't writable.
- Tests covering: debug-on path, debug-off path, read-only-tmp fallback, concurrent compile.
Related: NVBugs 6420444
Summary
When a user compiles a kernel via
cuda.core.Programwithdebug=Trueorlineinfo=True,cuda-gdbcannot show source lines because the programname=defaults to the literal string"default_program"and no file with that name exists on disk. The debugger reportsdefault_program:10 — No such file or directoryand users lose source-level debugging.This is tracked in NVBugs 6420444 (originally reported by Linaro). The customer was unblocked by a workaround: pass a real file path as
name=and write the source there manually. We want this to work by default.Proposed fix
When
debug=Trueorlineinfo=Trueis set onProgram(...):train_py__matmul.cu).name=.When neither debug flag is set, behavior is unchanged (no disk I/O, same label as today).
Impact on existing users
name=explicitly: zero change (their value wins).cuda-gdb/ traces / logs changes fromdefault_programto a real path. Cosmetic; easily searchable.Edge cases to handle
/tmpor sandboxed environments: fall back to today's label-only behavior on write failure, do not crash.tempfile.mkstempor PID+hash).TMPDIR; user-only permissions on the temp file.Acceptance criteria
cuda-gdbshows source lines when stepping into a kernel compiled withdebug=True, without any user-side workaround.Related: NVBugs 6420444