The DynamicLoader plug-in instance now lives up in lldb_private::Process where

it should live and the lldb_private::Process takes care of managing the 
auto pointer to the dynamic loader instance.

Also, now that the ArchSpec contains the target triple, we are able to 
correctly set the Target architecture in DidLaunch/DidAttach in the subclasses,
and then the lldb_private::Process will find the dynamic loader plug-in 
by letting the dynamic loader plug-ins inspect the arch/triple in the target.

So now the ProcessGDBRemote plug-in is another step closer to be purely 
process/platform agnostic.

I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly.

llvm-svn: 125650

1 files changed, 0 insertions, 5 deletions

diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
index 3e61ac6b840..7d5a361e98b 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -219,9 +219,6 @@ public:
     virtual lldb_private::Error
     DisableWatchpoint (lldb_private::WatchpointLocation *wp_loc);
 
-    virtual lldb_private::DynamicLoader *
-    GetDynamicLoader ();
-    
     virtual bool
     StartNoticingNewThreads();    
 
@@ -328,8 +325,6 @@ protected:
         eBroadcastBitAsyncThreadShouldExit          = (1 << 1)
     };
 
-
-    std::auto_ptr<lldb_private::DynamicLoader> m_dynamic_loader_ap;
     lldb_private::Flags m_flags;            // Process specific flags (see eFlags enums)
     lldb_private::Mutex m_stdio_mutex;      // Multithreaded protection for stdio
     GDBRemoteCommunication m_gdb_comm;