[Lldb-commits] [PATCH] D139054: Delay calling ObjC class list read utility functions very early in process startup

[Jason Molenda via Phabricator via lldb-commits]

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

When you are very early in process startup, before the system libraries have been initialized, and you run a simple expression, on Darwin systems, the Objective-C runtime plugin will run two utility functions to fetch the list of Objective-C class names in the inferior process.  These function calls can cause problems when the process launch is this early, and the user expression may have been a simple one like "p globalvar=1" which would be harmless and not require a jitted expression.

This patch adds code to debugserver to use libdyld calls to find the process launch state, returns it in a JSON reply for a "jGetDyldProcessState" packet.  This is passed up to DynamicLoaderMacOS::IsFullyInitialized() which checks for three specific process states that happen early in process startup, before system library initialization is completed.

Thread::SafeToCallFunctions() currently, on macOS, checks to see if the current thread is in __select, and does not run utility functions if it is.  This patch updates SafeToCallFunctions() to also call DynamicLoader::IsFullyInitialized(), and avoid running utility functions if that is the case.

Then there are updates to AppleObjCRuntimeV2 to check the threads for SafeToCallFunctions() before scanning for dynamic objective-c classes, or the static shared cache objective-c classes.

I added a test case which stops process launch on the first malloc() call, runs a simple expression, and confirms (via the types log) that we did not read the objc class lists.  Then it continues to main(), runs the simple expression again, and confirms (via types log) that it did read the objc class list.

The patch looks a bit big, mostly from piping the data from MachProcess::GetDyldProcessState() up to DynamicLoaderMacOS::IsFullyInitialized() through a handful of layers.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D139054

Files:
  lldb/docs/lldb-gdb-remote.txt
  lldb/include/lldb/Target/Process.h
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.cpp
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.h
  lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
  lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  lldb/source/Target/Thread.cpp
  lldb/test/API/macosx/early-process-launch/Makefile
  lldb/test/API/macosx/early-process-launch/TestEarlyProcessLaunch.py
  lldb/test/API/macosx/early-process-launch/main.c
  lldb/tools/debugserver/source/DNB.cpp
  lldb/tools/debugserver/source/DNB.h
  lldb/tools/debugserver/source/MacOSX/MachProcess.h
  lldb/tools/debugserver/source/MacOSX/MachProcess.mm
  lldb/tools/debugserver/source/RNBRemote.cpp
  lldb/tools/debugserver/source/RNBRemote.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D139054.479087.patch
Type: text/x-patch
Size: 29920 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20221130/58d5caa9/attachment-0001.bin>