Thank you so much Greg for your comments.
What architecture and os are you looking to support?
The OS is Linux and the primary use scenario is remote debugging.
is what I am trying to achieve and unfortunately that query did not
get much attention of the members.
Sorry about missing that. I will attempt to address this now:
I have to implement a debugger for our HW which comprises of CPU+GPU where
the GPU is coded in OpenCL and is accelerated through OpenVX API in C++
application which runs on CPU. Our requirement is we should be able to
debug the code running on both CPU and GPU simultaneously with in the same
LLDB debug session.
Interesting. There are two ways to accomplish this:
1 - Treat the CPU as one target and the GPU as another.
2 - Treat the CPU and GPU as one target
There are tricky areas for both, but for sanity I would suggest options #1.
The tricky things with solution #1 is how to manage switching the targets between the CPU and GPU when events happen (CPU stops, or GPU stops while the other is running or already stopped). We don’t have any formal “cooperative targets” yet, but we know they will exist in the future (client/server, vm code/vm debug of vm code, etc) so we will be happy to assist with questions if and when you get there.
Option #2 would be tricky as this would be the first target that has multiple architectures within one process. IF the CPU and GPU be be controlled separately, then I would go with option #1 as LLDB currently always stops all threads in a process when any thread stops. You would also need to implement different register contexts for each thread within such a target. It hasn’t been done yet, other than through the OS plug-ins that can provide extra threads to show in case you are doing some sort of user space threading.
GPU debugging is tricky since they usually don’t have a kernel or anything running on the hardware. Many examples I have seen so far will set a breakpoint in the program at some point by compiling the code with a breakpoint inserted, run to that breakpoint, and then if the user wants to continue, you recompile with breakpoints set at a later place and re-run the entire program again. Is your GPU any different? Since they will be used in an OpenCL context maybe your solution is better? We also had discussions on how to represent the various “waves” or sets of cores running the same program on the GPU. The easiest solution is to make one thread per distinct core on the GPU. The harder way would be to treat a thread as a collection of multiple cores and each variable value now can have one value per core.
We also discussed how to single step in a GPU program. Since multiple cores on the GPU are concurrently running the same program, there was discussion on how single stepping would work. If you are stepping and run into an if/then statement, do you walk through the if and the else at all times? One GPU professional was saying this is how GPU folks would want to see single stepping happen. So I think there is a lot of stuff we need to think about when debugging GPUs in general.
Looking at the mailing list archive I see that there were discussions about
this feature in LLDB here
What is the present status i.e. what works today and what is to be improved
of simultaneous multiple target debugging support in LLDB? Were the changes
contributed to LLDB mainstream?
So we currently have no cooperative targets in LLDB. This will be the first. We will need to discuss how hand off between the targets will occur and many other aspects. We will be sure to comment when and if you get to this point.
How can I access the material for [http://llvm.org/devmtg/2014-10/#bof5](http://llvm.org/devmtg/2014-10/#bof5)
(Future directions and features for LLDB)
Over the years we have talked about this, but it never really got into any real amount of detail and I don’t think the BoF notes will help you much.
Appreciate any help/guidance provided on the same.
I do believe approach #1 will work the best. The easiest thing you can do is to insulate LLDB from the GPU by putting it behind a GDB server boundary. Then we need to really figure out how we want to do GPU debugging.
Hopefully this filled in your missing answers. Let me know what questions you have.