The debugger supports attaching to applications that are already running. This may be useful to debug workloads that show hang-like behavior, such as deadlocks, infinite loops, etc.

Suppose you have an executing application with process ID 12345 and you want to use the debugger to inspect its state. Use the attach <PID> command to attach the debugger to your application. Here’s an example:

$ pgrep array-transform
12345
$ gdb-oneapi
...
(gdb) attach 12345
Attaching to process 12345
[New LWP 12346]
intelgt: gdbserver-ze started for process 12345.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Switching to Thread 0x7f219d194b80 (LWP 12345)]
0x00007f219f08e89b in sched_yield () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) info inferiors
  Num  Description                   Connection                                Executable
* 1    process 12345                 1 (native)                                /path/to/array-transform
  2    device [0000:3a:00.0].0       2 (extended-remote | gdbserver-ze --multi --once -)
  3    device [0000:3a:00.0].1       2 (extended-remote | gdbserver-ze --multi --once -)
  4    device [0000:9a:00.0].0       2 (extended-remote | gdbserver-ze --multi --once -)
  5    device [0000:9a:00.0].1       2 (extended-remote | gdbserver-ze --multi --once -)
Type "info devices" to see details of the devices.
(gdb)

The debugger attaches to both the host application that runs on the CPU and the workload(s) that were submitted by the application and run on the GPU(s). The inferiors that correspond to the host application and the devices are created and added to the debug session automatically by the auto-attach feature as usual. All the CPU and GPU threads are stopped by the debugger as part of the attach command. Once you get the GDB prompt, you can inspect the program state and resume the threads the same way as if the program was started from the debugger.