[Lldb-commits] [PATCH] Extend SBPlatform with capability to launch/terminate a process remotely. Integrate this change into test framework in order to spawn processes on a remote target.

[Greg Clayton]

See comments in the code and let me know what you think.


================
Comment at: include/lldb/API/SBPlatform.h:106-134
@@ -102,2 +105,31 @@
 
+    class SBPlatformLaunchCommand
+    {
+    public:
+        SBPlatformLaunchCommand (const char* command,
+                                 const char* working_dir,
+                                 const char* arch);
+
+        const char*
+        GetCommand () const;
+
+        const char*
+        GetWorkingDir () const;
+
+        const char*
+        GetArch () const;
+
+        const lldb::pid_t&
+        GetPID () const;
+
+        void
+        SetPID (const lldb::pid_t& pid);
+
+    private:
+        const std::string m_command;
+        const std::string m_working_dir;
+        const std::string m_arch;
+        lldb::pid_t m_pid;
+    };
+
     class SBPlatform
----------------
Can't we just use SBLaunchInfo instead of this?

 Also one thing to note: if you add anything to the lldb::SB API, you can only have one member variable: a pointer, an std::unique_ptr<> or a std::shared_pointer<>. Why? Because we are vending a C++ interface and you can't change the size of the class. When people link against the lldb.so, they need a consistent API and layout of classes in case they make classes that inherit from or use a lldb::SB class so the layout can never change. So to work around this we have rules:

1 - lldb::SB classes have one ivar (ptr, unique_ptr, or shared_ptr) which abstracts you from your implementation and makes sure the size of the lldb::SB object never changes
2 - no virtual functions so that all function lookups are based off of a pure name lookup by the dynamic linkers (no vtable that can change on you)
3 - No inheritance, or only inheritance based on other lldb::SB classes that obey the same rules

================
Comment at: include/lldb/API/SBPlatform.h:205-206
@@ -172,2 +204,4 @@
 
         SBError
+        Launch (SBPlatformLaunchCommand &launch_command);
+
----------------
Can't this just be a SBLaunchInfo?

================
Comment at: source/API/SBPlatform.cpp:262-304
@@ -259,1 +261,45 @@
 //----------------------------------------------------------------------
+// SBPlatformLaunchCommand
+//----------------------------------------------------------------------
+
+SBPlatformLaunchCommand::SBPlatformLaunchCommand (const char* command,
+                                                  const char* working_dir,
+                                                  const char* arch) :
+    m_command (command ? command : ""),
+    m_working_dir (working_dir ? working_dir: ""),
+    m_arch (arch ? arch: ""),
+    m_pid(LLDB_INVALID_PROCESS_ID)
+{
+}
+
+const char*
+SBPlatformLaunchCommand::GetCommand () const
+{
+    return m_command.c_str ();
+}
+
+const char*
+SBPlatformLaunchCommand::GetWorkingDir () const
+{
+    return m_working_dir.c_str ();
+}
+
+const char*
+SBPlatformLaunchCommand::GetArch () const
+{
+    return m_arch.c_str ();
+}
+
+const lldb::pid_t&
+SBPlatformLaunchCommand::GetPID () const
+{
+    return m_pid;
+}
+
+void
+SBPlatformLaunchCommand::SetPID (const lldb::pid_t& pid)
+{
+    m_pid = pid;
+}
+
+//----------------------------------------------------------------------
----------------
Hopefully this class doesn't need to exist, and we can just use SBLaunchInfo. If not, then all ivars (m_command, m_working_dir, m_arch and m_pid will need to go into a Impl class and the SBPlatformLaunchCommand class will need to have a std::unique_ptr<> to the imp class.

http://reviews.llvm.org/D7263

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/