- Added Platform::Kill call which raises SIGTERM signal in its base implementation and sends qKillSpawnedProcess request in case of PlatformRemoteGDBServer.
- Extended SBPLatform with Launch and Kill methods.
- A few fixes within GDBRemoteCommunicationClient and GDBRemoteCommunicationServer in order to properly deliver qProcessInfo response (disabling default PID caching).
- Small utility class hierarchy in lldbtest - _BaseProcess, _LocalProcess and _RemoteProcess to manage process launch/termination depending on test mode.
Details
Diff Detail
Event Timeline
test/functionalities/process_attach/TestProcessAttach.py | ||
---|---|---|
59 | 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. |
test/functionalities/process_attach/TestProcessAttach.py | ||
---|---|---|
59 | It makes sense since "process launch " allows to launch remote process in case of connected 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. |
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!
See comments in the code and let me know what you think.
include/lldb/API/SBPlatform.h | ||
---|---|---|
106–134 | 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 | |
205–212 | Can't this just be a SBLaunchInfo? | |
source/API/SBPlatform.cpp | ||
262–304 | 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. |
Please see my comments.
include/lldb/API/SBPlatform.h | ||
---|---|---|
106–134 | 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:
|
include/lldb/API/SBPlatform.h | ||
---|---|---|
106–134 |
I think we can make its friend. The ref() must be a private.
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.
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.
Committed as http://reviews.llvm.org/rL228230
include/lldb/API/SBPlatform.h | ||
---|---|---|
14–15 | Fixed. | |
source/API/SBPlatform.cpp | ||
219 | Done. |
We shouldn't need these in the header file. Only a reference to SBLaunchInfo is used below. Put them in the .cpp file.