In an internal development environment, lldb will attach to a gdb stub that can provide the address of a Mach-O fileset including the kernel binary. I added some preliminary support for the binary-addresses key in qProcessInfo in https://reviews.llvm.org/D130813; this patch fixes that support now that we have a live stub to run against, and passes the addr_t it gets through the PlatformList to see if any Platform knows how to handle it.
PlatformDarwinKernel will test the addr_t to see if it is a Mach-O Fileset, using Jonas' mach-o fileset plugin (https://reviews.llvm.org/D132433 et al). If it is a fileset, it will search for a com.apple.kernel entry, and if found, it will set the Process DynamicLoader to be DynamicLoaderDarwinKernel, and register the address of the com.apple.kernel entry in the fileset, to be loaded later by the DynamicLoader plugin.
The big trick with this is that I needed to do several Darwin specific things -- parse a Mach-O fileset in memory, detect if this is a Darwin kernel, set the Process DynamicLoader -- when I'm given only an addr_t in ProcessGDBRemote. Going through the Platform plugins and asking them if they can do these things given the addr_t was a way of accomplishing this from generic code.
This does mean that I introduced cross-platform dependencies in PlatformDarwinKernel. It needs to directly create a ObjectContainerMachOFileset object to use the FindEntry methods which are only available to the subclass. I need to instantiate a DynamicLoaderDarwinKernel object and set the Process to use it as the m_dyld. I like isolating all of this very-darwin-specific logic down in PlatformDarwinKernel, but I didn't see a good way of working around the dependencies.
Testing this is a trick I haven't figured out yet; I'd need a remote stub that will return the qProcessInfo binary-addresses key, have a Mach-O fileset there with a com.apple.kernel entry pointing to a binary that is structured like a Darwin kernel binary enough to trick lldb into loading it. It's possible to hand-test against a live environment, but faking enough of that to create a test would be a lot.
There will be a second patch dealing with corefiles, where I ended up making a lot of changes to ProcessMachCore so it's a rather large diff, and it was possible to separate the two halves, so I did.
Any feedback appreciated, I've been working on this one for a little bit now & a fresh set of eyes is welcome.
What makes the binary special? The comment above doesn't say. Can we give this a more descriptive name or omit the "Special" part?