[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

Thu Sep 8 15:05:42 PDT 2022

jasonmolenda created this revision.
jasonmolenda added reviewers: JDevlieghere, jingham.
jasonmolenda added a project: LLDB.
Herald added a subscriber: mgorny.
Herald added a project: All.
jasonmolenda requested review of this revision.
Herald added a subscriber: lldb-commits.

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.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133534

Files:
  lldb/include/lldb/Target/Platform.h
  lldb/include/lldb/Target/Process.h
  lldb/source/Core/DynamicLoader.cpp
  lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Target/Platform.cpp
  lldb/source/Target/Process.cpp
  lldb/unittests/Core/CMakeLists.txt
  lldb/unittests/Interpreter/CMakeLists.txt
  lldb/unittests/Platform/CMakeLists.txt
  lldb/unittests/Process/CMakeLists.txt
  lldb/unittests/SymbolFile/DWARF/CMakeLists.txt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D133534.458887.patch
Type: text/x-patch
Size: 20289 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20220908/e6e9b9c6/attachment-0001.bin>