osandov
libdrgn: add support for remote debugging via OpenOCD
OpenOCD may be used to establish a JTAG or SWD connection to a remote debugging target. This patch adds the necessary support to drgn for debugging a remote target using OpenOCD.
A new memory backend is added that issues memory transactions using OpenOCD's Tcl interface. With remote debugging using direct physical memory accesses there is no need for the kernel to have core dump support. Instead, we use the debugging information in the vmlinux file, together with information available in the physical memory of the target. A new arch-specific hook is added for figuring out the information in vmcoreinfo using the vmlinux file and the physical load address of the kernel, which must be supplied by the user.
With this patch, drgn can also act as a debugger for microcontroller firmware and other bare-metal programs that run without an MMU, using the same OpenOCD memory backend used for kernel debugging.
(Since this has dependencies on my other PRs, I included their commits in this PR.)
Looks like some of the RPM builders failed, but I didn't have much luck finding the actual build failure amongst the various log files under the Details link. Am I missing anything?
The logs are showing "No matching package to install: 'libkdumpfile-devel'", which is also happening on the main branch. So something appears to be busted with Fedora ELN, unrelated to your change.
Hi @osandov, do you think you will have a chance to look at this (or any of my other PRs) soon? I'm still actively using them for my kernel development work. I tried rebasing them onto the current main branch and ran into some merge conflicts, so for now I'm sticking with an older version of drgn. It looks like #312 and #315 still apply cleanly; if those go in I can try to rebase the rest.
Thanks for the ping, I'll make some time to look at your PRs this week.
@brenns10 since you've been looking at recovering the vmcoreinfo from core dumps lacking virtual address information, would you mind taking a look at that part of the top commit of this PR and sharing how that compares to what you've been doing?
Incidentally @pcc what sort of test setup are you using? I have a Raspberry Pi 4B that I've (somewhat) used with OpenOCD and some bare metal programs before. I might try to give it a go on that, once I dust everything off :)
Unfortunately my target is proprietary. I was thinking about getting a Raspberry Pi or something so that I can verify that this all works on publicly available hardware, but if you want to give it a go I'd be happy to help.