This is an archive of the discontinued LLVM Phabricator instance.

Add support for mach-o corefile loading of a platform binary
ClosedPublic

Authored by jasonmolenda on Sep 11 2022, 9:22 PM.

Details

Summary

This builds on the work in https://reviews.llvm.org/D133534 where support for a platform binary in live process debugging was added, and adds it to the Mach-O corefile loading as well. It has five changes:

  1. Add a name field to DynamicLoader::LoadBinaryWithUUIDAndAddress when we have a name, but may end up reading the binary out of memory, so we can use the name instead of a generic placeholder.
  1. In ObjectFileMachO::LoadCoreFileImages, check if the image address is a platform binary, load it and set the Platform/DynamicLoader as appropriate.
  1. Clean up the different cases in LoadCoreFileImages that handle corefile binary loading so it is clearer to read.
  1. Separate ProcessMachCore::DoLoadCore into half a dozen smaller helper methods. This method had grown quite large and it was difficult to trace the code flow through the different parts, and the complexity was unnecessary.
  1. In the new ProcessMachCore::LoadBinariesViaMetadata method which handles LC_NOTE type hints about binaries, when we have a main bin spec LC_NOTE that is explicitly a kernel, don't load the binary here -- just save the address and note that this will be a DynamicLoaderDarwinKernel dynamic loader, and leave the loading up to DynamicLoaderDarwinKernel to do correctly.

The minor cleanups in ObjectFileMachO::LoadCoreFileImages are easy to read in the phabracator if you only read the new version of the code. The (seriously needed) separation of ObjectFileMachO::LoadCoreFileImages into separate methods has made the diff very difficult to read. In my own reviewing of the patch, I've settled on simply reading through the new version of the file. Most of it is simple code movement, but I did make some cleanups to how sections of code were working -- for instance in the exhaustive search for a dyld or kernel binary, when multiple images that appear to be a kernel are found, I handle this better now by allowing DynamicLoaderDarwinKernel to pick the kernel image. It's common that we get fragments in a corefile that look similar to a kernel and can confuse the exhaustive search algorithm.

Similar to the problem of testing this with a live process, to test this I'd need to construct a corefile with a Mach-O fileset with a kernel image in it. It would not be easy to construct a test case without a corefile writer that synthesized all of this together, a not small bit of code, and it would also need to modify a test binary's mach header to look enough like a kernel that lldb would be tricked into using it.

Diff Detail

Event Timeline

jasonmolenda created this revision.Sep 11 2022, 9:22 PM
Herald added a project: Restricted Project. · View Herald Transcript
jasonmolenda requested review of this revision.Sep 11 2022, 9:22 PM
DavidSpickett added inline comments.
lldb/include/lldb/Target/DynamicLoader.h
231

Can you list what it might be constructed from? My guess:

  • the filename if loading from a path
  • <format>@<address> if loading from something in memory
lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
420–421

I think the various log messages could use __FUNCTION__ instead but hey let's not make this diff any bigger :) .
(the one time I know you need to write out the name is inside a lambda)

This revision is now accepted and ready to land.Sep 13 2022, 2:48 PM
jasonmolenda added inline comments.Sep 13 2022, 3:00 PM
lldb/include/lldb/Target/DynamicLoader.h
231

Thanks, this should have been clearer. Yeah this name is only used when a file cannot be found on the debug host; it may construct a module out of live memory. And in that case, it needs to make up a name for it.

lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
420–421

LOL I even updated the names of all the log messages to reflect their new methods, but of course you're right.

Update to address David's feedback.

This revision was automatically updated to reflect the committed changes.