[Lldb-commits] [lldb] db223b7 - Do qProcessInfo-hint binary loading later in Process setup

Jason Molenda via lldb-commits lldb-commits at lists.llvm.org
Wed Jan 18 12:33:14 PST 2023


Author: Jason Molenda
Date: 2023-01-18T12:33:05-08:00
New Revision: db223b7f01f70cbd8459d0db9b20dfe9a3b099a7

URL: https://github.com/llvm/llvm-project/commit/db223b7f01f70cbd8459d0db9b20dfe9a3b099a7
DIFF: https://github.com/llvm/llvm-project/commit/db223b7f01f70cbd8459d0db9b20dfe9a3b099a7.diff

LOG: Do qProcessInfo-hint binary loading later in Process setup

The remote stub may give lldb hints about binaries to
be loaded, especially in a firmware type environment, and
relay those hints in the qProcessInfo response.  The
binary loading was done very early in Process setup, before
we had any threads, and this made it complicated for people
to write dSYM python scripts which need access to a thread.
Delay the binary loading until a bit later in the Process
startup.

Differential Revision: https://reviews.llvm.org/D141972
rdar://104235301

Added: 
    

Modified: 
    lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
    lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h

Removed: 
    


################################################################################
diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 2f3a81fedd0b9..de8f2df52f23b 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -555,58 +555,6 @@ Status ProcessGDBRemote::DoConnectRemote(llvm::StringRef remote_url) {
         }
       }
 
-      // The remote stub may know about the "main binary" in
-      // the context of a firmware debug session, and can
-      // give us a UUID and an address/slide of where the
-      // binary is loaded in memory.
-      UUID standalone_uuid;
-      addr_t standalone_value;
-      bool standalone_value_is_offset;
-      if (m_gdb_comm.GetProcessStandaloneBinary(
-              standalone_uuid, standalone_value, standalone_value_is_offset)) {
-        ModuleSP module_sp;
-
-        if (standalone_uuid.IsValid()) {
-          const bool force_symbol_search = true;
-          const bool notify = true;
-          DynamicLoader::LoadBinaryWithUUIDAndAddress(
-              this, llvm::StringRef(), standalone_uuid, standalone_value,
-              standalone_value_is_offset, force_symbol_search, notify);
-        }
-      }
-
-      // The remote stub may know about a list of binaries to
-      // force load into the process -- a firmware type situation
-      // where multiple binaries are present in virtual memory,
-      // and we are only given the addresses of the binaries.
-      // Not intended for use with userland debugging when we
-      // a DynamicLoader plugin that knows how to find the loaded
-      // binaries and will track updates as binaries are added.
-
-      std::vector<addr_t> bin_addrs = m_gdb_comm.GetProcessStandaloneBinaries();
-      if (bin_addrs.size()) {
-        UUID uuid;
-        const bool value_is_slide = false;
-        for (addr_t addr : bin_addrs) {
-          const bool notify = true;
-          // First see if this is a special platform
-          // binary that may determine the DynamicLoader and
-          // Platform to be used in this Process/Target in the
-          // process of loading it.
-          if (GetTarget()
-                  .GetDebugger()
-                  .GetPlatformList()
-                  .LoadPlatformBinaryAndSetup(this, addr, notify))
-            continue;
-
-          const bool force_symbol_search = true;
-          // Second manually load this binary into the Target.
-          DynamicLoader::LoadBinaryWithUUIDAndAddress(
-              this, llvm::StringRef(), uuid, addr, value_is_slide,
-              force_symbol_search, notify);
-        }
-      }
-
       const StateType state = SetThreadStopInfo(response);
       if (state != eStateInvalid) {
         SetPrivateState(state);
@@ -1007,6 +955,9 @@ void ProcessGDBRemote::DidLaunchOrAttach(ArchSpec &process_arch) {
     }
   }
 
+  // Target and Process are reasonably initailized;
+  // load any binaries we have metadata for / set load address.
+  LoadStubBinaries();
   MaybeLoadExecutableModule();
 
   // Find out which StructuredDataPlugins are supported by the debug monitor.
@@ -1028,6 +979,59 @@ void ProcessGDBRemote::DidLaunchOrAttach(ArchSpec &process_arch) {
   }
 }
 
+void ProcessGDBRemote::LoadStubBinaries() {
+  // The remote stub may know about the "main binary" in
+  // the context of a firmware debug session, and can
+  // give us a UUID and an address/slide of where the
+  // binary is loaded in memory.
+  UUID standalone_uuid;
+  addr_t standalone_value;
+  bool standalone_value_is_offset;
+  if (m_gdb_comm.GetProcessStandaloneBinary(standalone_uuid, standalone_value,
+                                            standalone_value_is_offset)) {
+    ModuleSP module_sp;
+
+    if (standalone_uuid.IsValid()) {
+      const bool force_symbol_search = true;
+      const bool notify = true;
+      DynamicLoader::LoadBinaryWithUUIDAndAddress(
+          this, "", standalone_uuid, standalone_value,
+          standalone_value_is_offset, force_symbol_search, notify);
+    }
+  }
+
+  // The remote stub may know about a list of binaries to
+  // force load into the process -- a firmware type situation
+  // where multiple binaries are present in virtual memory,
+  // and we are only given the addresses of the binaries.
+  // Not intended for use with userland debugging, when we use
+  // a DynamicLoader plugin that knows how to find the loaded
+  // binaries, and will track updates as binaries are added.
+
+  std::vector<addr_t> bin_addrs = m_gdb_comm.GetProcessStandaloneBinaries();
+  if (bin_addrs.size()) {
+    UUID uuid;
+    const bool value_is_slide = false;
+    for (addr_t addr : bin_addrs) {
+      const bool notify = true;
+      // First see if this is a special platform
+      // binary that may determine the DynamicLoader and
+      // Platform to be used in this Process and Target.
+      if (GetTarget()
+              .GetDebugger()
+              .GetPlatformList()
+              .LoadPlatformBinaryAndSetup(this, addr, notify))
+        continue;
+
+      const bool force_symbol_search = true;
+      // Second manually load this binary into the Target.
+      DynamicLoader::LoadBinaryWithUUIDAndAddress(this, llvm::StringRef(), uuid,
+                                                  addr, value_is_slide,
+                                                  force_symbol_search, notify);
+    }
+  }
+}
+
 void ProcessGDBRemote::MaybeLoadExecutableModule() {
   ModuleSP module_sp = GetTarget().GetExecutableModule();
   if (!module_sp)

diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
index aae643240702e..83f0adfe35afb 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -374,6 +374,7 @@ class ProcessGDBRemote : public Process,
   bool UpdateThreadIDList();
 
   void DidLaunchOrAttach(ArchSpec &process_arch);
+  void LoadStubBinaries();
   void MaybeLoadExecutableModule();
 
   Status ConnectToDebugserver(llvm::StringRef host_port);


        


More information about the lldb-commits mailing list