libcudadebugger.so logger

I've done some research of libcudadebugger.so internals - seems that it has exactly the same patterns:

• functions table returned by GetCUDADebuggerAPI located in .data section so you can patch any callback address
• and each API function has logger
  

This last fact is strange - while loggers from libcuda.so were used by debugger then who consume logs from debugger itself? Check code to load those loggers:

  lea     rdi, aNvtxInjection6          ; "NVTX_INJECTION64_PATH"
  call    _getenv
  mov     rdi, rax                      ; file
  test    rax, rax
  jz      short loc_14B160
  mov     esi, 1                        ; mode
  call    _dlopen
  mov     r13, rax
  test    rax, rax
  jz      short loc_14B190
  lea     rsi, aInitializeinje_1        ; "InitializeInjectionNvtx2"
  mov     rdi, rax                      ; handle
  call    _dlsym
  test    rax, rax
  jz      short loc_14B1A0
  lea     rdi, sub_14A270
  call    rax 


Very straightforward - load shared library from env var NVTX_INJECTION64_PATH and call function InitializeInjectionNvtx2 - part of Cupti API. Btw excellent injection hook

 

Unfortunately these loggers don't collect parameters of API functions - only their names in packets with fixed size 0x30 bytes:

  lea     rax, aFailedCreatede+7        ; "CreateDebuggerSession"
  mov     [rbp+var_18], rax
  mov     rax, cs:dbg_log
  mov     [rbp+var_20], 0
  mov     dword ptr [rbp+var_40], 300003h
  mov     dword ptr [rbp+var_20], 1
  movaps  [rbp+var_30], xmm0
  test    rax, rax
  jz      loc_1470AC
  lea     rdx, [rbp+var_40]
  mov     r12, rdx
  mov     rdi, rdx
  call    rax


Name of called function located at offset 0x28 and in logs looks like

10/02/2026 15:11:13 CreateDebuggerSession
00000000  03 00 30 00-00 00 00 00|01 00 00 00-4A 84 F9 FF  ..0.........J...
00000010  00 00 00 00-00 00 00 00|00 00 00 00-00 00 00 00  ................
00000020  01 00 00 00-00 00 00 00|D9 70 E3 52-55 15 00 00  .........p.RU...


 

Source code for standalone logger

Tracepoints

I also discovered lots of tracepoints inside libcudadebugger.so very similar to Windows Tlg:

  movzx   eax, cs:word_9AA8E8
  cmp     ax, 1
  jg      short loc_147058
  test    ax, ax
  jz      loc_147080

loc_146FE4:                 ; CODE XREF: CreateDebuggerSession+16B↓j
  cmp     ax, 1
  jnz     short loc_147058
  cmp     cs:byte_9AA8EC, 31h ; '1'
  jbe     short loc_147058

loc_146FF3:                 ; CODE XREF: CreateDebuggerSession+15E↓j
  cmp     cs:byte_9B83CF, 0FFh
  jz      short loc_147058
  lea     rax, aCreateFailedSt  ; "Create failed. status=0x%x callResult=0"...

...

  call log_report


They have structure like tlg {
  const char *prefix;
  unsigned short level; // offset 0x8
  unsigned char mask1, mask2, mask3; // offset 0xa, 0xb & 0xc 
};

They are not collected in some centralized way so there are no official way to turn them on. But sure this is not big problem - you can find then in memory and patch level to 1 and masks for example to 'z' - see method patch_tlg

Patch for cuda-gdb

I also made integration of libcudadebugger.so logger with cuda-gdb

First patch adds two new options for logger:

1. --log=log.file for log filename
2. --verbose to turn on tracepoints - note that I reused info_verbose var - it is ruled by set verbose on/off

Second calls my check_cudbg function from cuda_debugapi::initialize

 

Note that you also should add libde_bg.a & libudis86.a to Makefile, something like

gdb$(EXEEXT): gdb.o $(LIBGDB_OBS) $(CDEPS) $(TDEPLIBS) $(LIBCUDACORE)
        $(SILENCE) rm -f gdb$(EXEEXT)
        $(ECHO_CXXLD) $(CC_LD) $(INTERNAL_LDFLAGS) $(WIN32LDAPP) \
                -o gdb$(EXEEXT) gdb.o $(LIBGDB_OBS) /home/redp/disc/src/cuda-ptx/src/denvdis/cudaso/libde_bg.a /home/redp/disc/udis86/libudis86/libudis86.a \

Bonus

While checking corresponding loggers in libcupti I found SASS trace stubs inside it, so I ripped them out and put into github. They contains so called TraceKernels (written in nvasm_internal) and functions like tools_l2flush, tools_memcmp etc