[Lldb-commits] [lldb] [lldb-server] Add accelerator plugin infrastructure for debugging hardware accelerators like gpus (PR #198907)

[Greg Clayton via lldb-commits]

clayborg wrote:

> > NOTE: Sorry for the big patch, We tried to make self contained as much as possible.
> 
> I thought it was quite compact actually. Maybe because the changes are varied. The more similar the changes are to each other, the less tolerance I have for a large PR.
> 
> > jAcceleratorPluginInitialize GDB remote packet and its implementation in handlers, request and response.
> 
> Ultimately I don't care too much about the name, so this is more about understanding, but can you tell me what `jAcceleratorPluginInitialize` actually initializes and what work is involved in that?
> 
> At a glance it seems that it is more like `jAcceleratorPluginList`. The result may be used to initialize something in `lldb` but that's like calling memory read `memoryReadBufferInitialize`. The server doesn't care that the client is going to do whatever action with the result in that case.

It allows any GPU plug-ins to initialize themselves. Right now they are just declaring themselves, but in the future the plug-ins will return GPUActions (will be renamed to AccleratorActions for upstream) which can set breakpoints and send back any LLDB GPU settings. See this branch for fully working AMD and Mock GPU debugging:

https://github.com/clayborg/llvm-project/tree/llvm-server-plugins

> 
> If it looks this way just because the mock plugin is, a mock plugin, fair enough. If you could give some examples of work that needs to be done at this step for real plugins, that would be very helpful.

Real GPU plug-ins will return breakpoints that need to be set in the native program that is running. This allows the native program to hit breakpoints in the GPU driver at important times in the lifetime of a code that will run on the GPU. The breakpoints are internal breakpoints with callbacks set on them that will eventually call into the GPU plug-in and let them know that their breakpoint was hit. This allows complete control over the GPU and avoids race conditions. These breakpoints are used to:
- find out if and when the GPU is enabled from the native program and that callback can return more GPUActions (more breakpoints and other things) in response to this. We don't want a GPU process to show up in LLDB unless the main program actually runs the GPU
- load/unload modules in the GPU process
- detect when the first kernel is launched as just because the GPU connection was initialized, it doesn't mean there is something to debug yet

So checkout the branch URL and have a look a complete working system with tests if you need to see what will be coming. There is a AMD plug-in and a more complete Mock GPU plug-in with full testing of all of the functionality in there with address space support, AMD debugging and more.




https://github.com/llvm/llvm-project/pull/198907