[lldb-dev] Returning multiple values in Python API function

[Francis Ricci via lldb-dev]

On Fri, Oct 21, 2016 at 3:30 PM, Greg Clayton <gclayton at apple.com> wrote:
>
>> On Oct 21, 2016, at 1:03 PM, Francis Ricci via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>
>> Hi all,
>>
>> I'm looking to add Platform::LaunchGDBServer() to the SBPlatform API,
>> but it requires two return values - an lldb::pid_t and a string url.
>> Internally, we just pass by reference, but we can't do that in the
>> API. Any suggestions on how to do this, since we can't pass primitives
>> by reference from Python?
>>
>> My current thinking was to use the pid_t as the return value, and then
>> figure out a way to communicate the string information as an "out"
>> function parameter. Ideas there included using an SBStream&, as the
>> GetDescription() functions do, but that doesn't seem optimal.
>>
>> In standard Python, we'd just use a tuple return value, but I don't
>> see any way to do that using the swig interface.
>>
>> The reasoning behind adding this API function is to prevent the
>> platform-mode GdbRemote tests from launching the gdbserver using an
>> 'A' packet instead of the standard 'qLaunchGDBServer' packet.
>
> I am still unclear as to why you want this? An lldb-server that is launched in platform mode shouldn't use the 'A' packet at all.

Right. The problem is that our test suite (specifically the
lldb-server tests) uses the 'A' packet to spawn the inferior for
lldb-server's which are launched in platform mode.

> Can you elaborate on why you need this more? Why do we need to prevent it from using an 'A' packet in the first place? What is leading to this happening?

gdbremote_testcase.py, in launch_debug_monitor, calls
self.spawnSubprocess() on the lldb-server exe.

This in turn calls _RemoteProcess.launch() in lldbtest.py, which calls
lldb.remote_platform.Launch(), which will use the 'A' packet, with the
path to the lldb-server.

I think this is broken, and the qLaunchGDBServer packet should be used
instead. The problem is that there currently isn't a good way to use
this packet from the Python API.

It is somewhat odd to me that the platform-mode lldb-server even
accepts the 'A' packet, but it appears to, given that the `Handle_A`
method is contained in `GDBRemoteCommunicationServerCommon` and not
`GDBRemoteCommunicationServerLLGS`.

>  Why do you want to launch on manually?

As far as I know, the lldb-server tests send packets manually in
general, since they don't run with the full lldb, and just a python
stub to test the remote protocols.