LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide

an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a "default" platform that will be
used unless a new platform is selected. Platforms are responsible for things
such as:
- getting process information by name or by processs ID
- finding platform files. This is useful for remote debugging where there is 
  an SDK with files that might already or need to be cached for debug access.
- getting a list of platform supported architectures in the exact order they
  should be selected. This helps the native x86 platform on MacOSX select the
  correct x86_64/i386 slice from universal binaries.
- Connect to remote platforms for remote debugging
- Resolving an executable including finding an executable inside platform
  specific bundles (macosx uses .app bundles that contain files) and also
  selecting the appropriate slice of universal files for a given platform.

So by default there is always a local platform, but remote platforms can be
connected to. I will soon be adding a new "platform" command that will support
the following commands:
(lldb) platform connect --name machine1 macosx connect://host:port
Connected to "machine1" platform.
(lldb) platform disconnect macosx

This allows LLDB to be well setup to do remote debugging and also once 
connected process listing and finding for things like:
(lldb) process attach --name x<TAB>

The currently selected platform plug-in can now auto complete any available
processes that start with "x". The responsibilities for the platform plug-in
will soon grow and expand.

llvm-svn: 127286

1 files changed, 17 insertions, 37 deletions

diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index df09bf37d95..ab6c9150b97 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -164,26 +164,6 @@ ProcessGDBRemote::GetPluginVersion()
 }
 
 void
-ProcessGDBRemote::GetPluginCommandHelp (const char *command, Stream *strm)
-{
-    strm->Printf("TODO: fill this in\n");
-}
-
-Error
-ProcessGDBRemote::ExecutePluginCommand (Args &command, Stream *strm)
-{
-    Error error;
-    error.SetErrorString("No plug-in commands are currently supported.");
-    return error;
-}
-
-Log *
-ProcessGDBRemote::EnablePluginLogging (Stream *strm, Args &command)
-{
-    return NULL;
-}
-
-void
 ProcessGDBRemote::BuildDynamicRegisterInfo (bool force)
 {
     if (!force && m_register_info.GetNumRegisters() > 0)
@@ -2456,23 +2436,23 @@ ProcessGDBRemote::GetDispatchQueueNameForThread
     return dispatch_queue_name.c_str();
 }
 
-uint32_t
-ProcessGDBRemote::ListProcessesMatchingName (const char *name, StringList &matches, std::vector<lldb::pid_t> &pids)
-{
-    // If we are planning to launch the debugserver remotely, then we need to fire up a debugserver
-    // process and ask it for the list of processes. But if we are local, we can let the Host do it.
-    if (m_local_debugserver)
-    {
-        return Host::ListProcessesMatchingName (name, matches, pids);
-    }
-    else 
-    {
-        // FIXME: Implement talking to the remote debugserver.
-        return 0;
-    }
-
-}
-
+//uint32_t
+//ProcessGDBRemote::ListProcessesMatchingName (const char *name, StringList &matches, std::vector<lldb::pid_t> &pids)
+//{
+//    // If we are planning to launch the debugserver remotely, then we need to fire up a debugserver
+//    // process and ask it for the list of processes. But if we are local, we can let the Host do it.
+//    if (m_local_debugserver)
+//    {
+//        return Host::ListProcessesMatchingName (name, matches, pids);
+//    }
+//    else 
+//    {
+//        // FIXME: Implement talking to the remote debugserver.
+//        return 0;
+//    }
+//
+//}
+//
 bool
 ProcessGDBRemote::NewThreadNotifyBreakpointHit (void *baton,
                              lldb_private::StoppointCallbackContext *context,