This is an archive of the discontinued LLVM Phabricator instance.

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.
ClosedPublic

Authored by ovyalov on Jan 29 2015, 12:37 PM.

Details

Reviewers
vharron
clayborg
Summary
  1. Added Platform::Kill call which raises SIGTERM signal in its base implementation and sends qKillSpawnedProcess request in case of PlatformRemoteGDBServer.
  2. Extended SBPLatform with Launch and Kill methods.
  3. A few fixes within GDBRemoteCommunicationClient and GDBRemoteCommunicationServer in order to properly deliver qProcessInfo response (disabling default PID caching).
  4. Small utility class hierarchy in lldbtest - _BaseProcess, _LocalProcess and _RemoteProcess to manage process launch/termination depending on test mode.

Diff Detail

Event Timeline

ovyalov updated this revision to Diff 18981.Jan 29 2015, 12:37 PM
ovyalov retitled this revision from to 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..
ovyalov updated this object.
ovyalov edited the test plan for this revision. (Show Details)
ovyalov added reviewers: clayborg, vharron.
ovyalov added a subscriber: Unknown Object (MLST).
vharron requested changes to this revision.Jan 29 2015, 1:51 PM
vharron edited edge metadata.
vharron added inline comments.
test/functionalities/process_attach/TestProcessAttach.py
59 ↗(On Diff #18981)

Hi Greg,

In lldb, when I create a target, it is created in the context of the selected platform. Currently, when I launch a process, it is launched in the context of the selected target.

I would prefer 'process attach' to be done in the context of the currently selected platform. That way, whether you don't need to remember attaching to local/remote processes.

This revision now requires changes to proceed.Jan 29 2015, 1:51 PM
ovyalov added inline comments.Jan 29 2015, 5:51 PM
test/functionalities/process_attach/TestProcessAttach.py
59 ↗(On Diff #18981)

It makes sense since "process launch " allows to launch remote process in case of connected platform.
I hacked a quick change for CommandObjectProcess to make it use platform:

if (platform_sp->CanDebugProcess())
 {
     process_sp = platform_sp->Attach(m_options.attach_info, m_interpreter.GetDebugger(), nullptr, error); // PlatformRemoteGDBServer needs to call HijackProcessEvents on process.
 }
 else
 {
     const char *plugin_name = m_options.attach_info.GetProcessPluginName();
     process_sp = target->CreateProcess (m_interpreter.GetDebugger().GetListener(), plugin_name, NULL);
     if (process_sp)
     {
         process_sp->HijackProcessEvents(listener_sp.get());
         error = process_sp->Attach (m_options.attach_info);
     }
 }

It's working remotely but crashing locally for me.
So, I can revert TestProcessAttach.py in this CL and then follow-up with CL for CommandObjectProcess.

ovyalov updated this revision to Diff 19206.Feb 2 2015, 6:07 PM
ovyalov edited edge metadata.

I reverted TestProcessAttach changes and merged with http://reviews.llvm.org/D7358 - no regressions noticed for local test runs on Ubuntu and OSX, remote Linux->Linux execution of TestProcessAttach works fine.
Please take another look.

Thank you!

Friendly ping.

clayborg requested changes to this revision.Feb 3 2015, 1:14 PM
clayborg edited edge metadata.

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

include/lldb/API/SBPlatform.h
107–135

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

177–184

Can't this just be a SBLaunchInfo?

source/API/SBPlatform.cpp
261–303

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.

This revision now requires changes to proceed.Feb 3 2015, 1:14 PM

Please see my comments.

include/lldb/API/SBPlatform.h
107–135

Thanks for suggestions and context.

I think it makes sense to use SBLaunchInfo instead of SBPlatformLaunchCommand since SBLaunchInfo is a wrapper around ProcessLaunchInfo which Platform::LaunchProcess takes as a parameter. A few follow-up questions:

  • Is it ok to remove friendship between SBLaunchInfo and SBTarget and make SBLaunchInfo::ref public since it will be used by SBPlatform and SBTarget? Or we can make SBPlatform its friend as well..
  • I'm going to add SBLaunchInfo::GetProcessID that will delegate to ProcessLaunchInfo::SBLaunchInfo - so, I can grab pid of launched process.
  • Does it sound okay to extract SBLaunchInfo into separate SBLaunchInfo.h(cpp) files?
ki.stfu added a subscriber: ki.stfu.Feb 3 2015, 3:18 PM
ki.stfu added inline comments.
include/lldb/API/SBPlatform.h
107–135

Is it ok to remove friendship between SBLaunchInfo and SBTarget and make SBLaunchInfo::ref public since it will be used by SBPlatform and SBTarget? Or we can make SBPlatform its friend as well..

I think we can make its friend. The ref() must be a private.

Does it sound okay to extract SBLaunchInfo into separate SBLaunchInfo.h(cpp) files?

Yes.

Is it ok to remove friendship between SBLaunchInfo and SBTarget and make SBLaunchInfo::ref public since it will be used by SBPlatform and SBTarget? Or we can make SBPlatform its friend as well..

Make SBPlatform a friend as well

I'm going to add SBLaunchInfo::GetProcessID that will delegate to ProcessLaunchInfo::SBLaunchInfo - so, I can grab pid of launched process.

sounds good

Does it sound okay to extract SBLaunchInfo into separate SBLaunchInfo.h(cpp) files?

Sure thing. Feel free to do the same for SBAttachInfo if you have time. I can deal with the fallout in the Xcode project if you don't have a Mac once you get those in.

ovyalov updated this revision to Diff 19294.Feb 3 2015, 6:00 PM
ovyalov edited edge metadata.

Extracted SBLaunchInfo (with added GetProcessID method) into a separate file and updated all build dependencies - checked on Ubuntu and OSX, didn't spot any regressions.
The CL's already become pretty big - let me extract SBAttachInfo with another CL.

Please take another look.
Thank you.

clayborg requested changes to this revision.Feb 4 2015, 9:53 AM
clayborg edited edge metadata.

Changes inlined into code as comments.

include/lldb/API/SBPlatform.h
14–15

We shouldn't need these in the header file. Only a reference to SBLaunchInfo is used below. Put them in the .cpp file.

source/API/SBPlatform.cpp
218

Remove this line so there are no diffs generated here.

This revision now requires changes to proceed.Feb 4 2015, 9:53 AM
ovyalov updated this revision to Diff 19333.Feb 4 2015, 10:12 AM
ovyalov edited edge metadata.

Fixed according to suggestions.

clayborg accepted this revision.Feb 4 2015, 11:02 AM
clayborg edited edge metadata.

lgtm

vharron accepted this revision.Feb 19 2015, 10:12 AM
vharron edited edge metadata.
This revision is now accepted and ready to land.Feb 19 2015, 10:12 AM
ovyalov closed this revision.May 10 2015, 9:43 AM
include/lldb/API/SBPlatform.h
14–15

Fixed.

source/API/SBPlatform.cpp
218

Done.