[Lldb-commits] [PATCH] D88387: Create "skinny corefiles" for Mach-O with process save-core / reading

Fri Oct 2 23:05:23 PDT 2020

jasonmolenda updated this revision to Diff 295963.
jasonmolenda added a comment.
Herald added a subscriber: dang.

This patch update incorporates most of Greg's suggestions.  Most importantly, I isolated all of the loading of the binaries specified in the corefile down into ObjectFileMachO so I didn't have to add so much special case API to the ObjectFile base API.

Greg made a case in direct email for the usefulness of a full coredump -- e.g. people may save a skinny core on one mac system, and send it to someone on a different mac system where the system libraries are all different, and no backtraces would be meaningful.  This patch implements a -f option to process save-core to force a full coredump, if the system defaults to skinny (as it will on macos).

The alternative we were discussing is a hybrid approach where the core dumper saves all of the memory pages that cover the binary, for images that are currently executing on a thread.  We'd need the full symbol table, mach-o header, and text which is executing, so it's probably easier to just copy the whole thing in than to try to pare it back.  This is an interesting idea, and most of the groundwork is laid for it - we are already computing which libraries are actively executing and noting that in the corefile metadata so lldb can do more expensive searches for those binary images.

I switched to using the RangeDataVector container, but it has a little bug in the CombineConsecutiveEntriesWithEqualData where consecutive entries with the same Data value are combined, even if their ranges are not consecutive.  So you could get a vast address range claimed if a user process page and a shared cache page had the same protections.  Fixing that and writing a test case, I found a second problem where RangeDataVector isn't setting its 'upper_bound' field properly for this use case and searches don't work as they should.  At which point I booted it out of the patch and went back to the hand-rolled container that I'd started with; I'll try to look at RangeDataVector more closely next week and switch to using it in this method.  It is a cleaner and simpler approach.

I also got rid of the "executing uuids" LC_NOTE - as Greg pointed out, I have a perfectly good unused field for alignment in the binary image entries already, using that to flag executing images was even easier.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88387/new/

https://reviews.llvm.org/D88387

Files:
  lldb/docs/lldb-gdb-remote.txt
  lldb/include/lldb/Core/PluginManager.h
  lldb/include/lldb/Symbol/ObjectFile.h
  lldb/include/lldb/Target/MemoryRegionInfo.h
  lldb/include/lldb/lldb-private-interfaces.h
  lldb/source/API/SBProcess.cpp
  lldb/source/Commands/CommandObjectProcess.cpp
  lldb/source/Commands/Options.td
  lldb/source/Core/PluginManager.cpp
  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
  lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
  lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
  lldb/test/API/macosx/skinny-corefile/Makefile
  lldb/test/API/macosx/skinny-corefile/TestSkinnyCorefile.py
  lldb/test/API/macosx/skinny-corefile/main.c
  lldb/test/API/macosx/skinny-corefile/present.c
  lldb/test/API/macosx/skinny-corefile/present.h
  lldb/test/API/macosx/skinny-corefile/to-be-removed.c
  lldb/test/API/macosx/skinny-corefile/to-be-removed.h
  lldb/tools/debugserver/source/DNBDefs.h
  lldb/tools/debugserver/source/MacOSX/MachVMMemory.cpp
  lldb/tools/debugserver/source/RNBRemote.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D88387.295963.patch
Type: text/x-patch
Size: 60302 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20201003/ffb44355/attachment-0001.bin>