Upstreaming basic support for accelerators

[wallace]

First of all, thank you very much for skimming through the code and leaving feedback. This makes me very happy

@aktemur

Isn’t this a consequence of GDB’s all-stop mode, which is default behavior, rather than target configuration? In non-stop mode, the user would be able to keep other (CPU and GPU) threads running while inspecting a stopped GPU thread. Even in all-stop mode, it should be possible to resume a single thread/wave asynchronously (with the continue & command using scheduler-locking), then switch to a CPU thread and resume it, too, so that the deadlock is resolved (I’m assuming the accelerator supports individual resume of threads/waves; it’s already possible for CPU threads.)

You are right to some extent. For sure the gdb gpu architects could have used two targets. Nothing prevented that, but they opted for a single target, which perhaps is more aligned with the heterogenous programming philosophy that the compiler tries to adhere to. It turns out that in practice that philosophy has some drawbacks for debugging, as explained above. W.r.t. to all-stop vs non-stop, all-stop is the default on all platforms and non-stop is only available on certain targets, so the restrictions on the lock-step situation are based on the fact that the only configuration that works for all platforms is all-stop. Still, there are some interesting situations that arise with non-stop. When you step a gpu thread, you are actually stepping a group of threads, which would require some new abstractions on top of non-stop mode; this is all doable, but it turns out that there’s no easy path with the non-stop situation.

@aktemur

Handling the GPU part as a separate inferior means that there will be moments where the device would be idle, i.e. no threads are running. Skimming through the git repo, I noticed that you defined a shadow/fallback thread, so that there would always exist a thread from LLDB’s perspective. Do you plan to keep this fallback thread or get rid of it in the future?

Yes, this is something inconvenient. What complicates further this situation is that once you initialize the gpu, you never shut it down, which means that if your host will launch multiple kernels sequencially, there will indeed be multiple periods of time in which there will be no gpu threads, and after the last kernel finished, the gpu will have no running threads any more and lldb doesn’t know that there will no additional kernels. We have two paths there: 1) Teach lldb how to handle a target that might not have threads. Right now it’s expecting forcefully at least one thread. 2) Use a fake/placeholder thread that represents an idle gpu. I opted for the second option in my current implementation because it’s the easiest and it hasn’t created any bad behavior yet. I’m sure that if someone tries to use lldb via scripts they will need to add a special handler for this situation, but it’s just that 1) is way more work and it’s very intrusive to lldb. I’m open to do 1) if we eventually see that it’s really necessary though.