[lldb-dev] Can I call a python script from LLDB c++ code?

Wed Apr 4 09:16:47 PDT 2018

> On Apr 3, 2018, at 4:30 PM, Ted Woodward <ted.woodward at codeaurora.org> wrote:
> 
> Responses inline
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> 
>> -----Original Message-----
>> From: Greg Clayton [mailto:clayborg at gmail.com]
>> Sent: Tuesday, April 03, 2018 5:19 PM
>> To: Ted Woodward <ted.woodward at codeaurora.org>
>> Cc: lldb-dev at lists.llvm.org
>> Subject: Re: [lldb-dev] Can I call a python script from LLDB c++ code?
>> 
>> 
>> 
>>> On Apr 3, 2018, at 12:18 PM, Ted Woodward via lldb-dev <lldb-
>> dev at lists.llvm.org> wrote:
>>> 
>>> LLDB for Hexagon can automatically launch and connect to the Hexagon
>>> simulator, much like LLDB can launch and connect to debugserver/lldb-
>> server.
>>> I've got a copy of GDBRemoteCommunication::StartDebugserverProcess
>>> that does this. A copy because there are feature incompatibilities
>>> between hexagon-sim and debugserver/lldb-server.
>>> 
>>> On a hardware target, our OS has a debug stub. We'd like to run the
>>> lldb test suite talking to this stub on the simulator, instead of
>>> talking to the RSP interface the simulator publishes. We have a module
>>> that will forward ports to the OS under simulation, but to do this I
> need to:
>>> 1) open an http connection to port x
>>> 2) parse some xml coming back that contains the actual port for the
>>> stub I want to connect to
>>> 3) connect to the new port
>> 
>> 
>> Can't you forward ports in advance and then run lldb-server in platform
> mode
>> and tell it to use only those ports? Then lldb-server will do everything
> it needs.
>> There is a port offset option to lldb-server that can be used in case the
> lldb-
>> server that runs on the simulator returns say port 1111, but it needs to
> have
>> 10000 added to it...
> 
> Short answer - no.  It's a custom stub, not lldb-server, but that's not the
> issue.
> The issue is that the mechanism to get data into the simulation mimics what
> we do on
> hardware, where the DSP doesn't have access to the outside world, and
> everything
> goes through an Android app. The system publishes 1 port per process that
> the stub
> controls. These ports are picked randomly, and are set up when the http
> connection
> is made. The data that is read over that connection needs to be parsed to
> find the
> ports that the stub is publishing.
> 
>>> I have a python script that will do this, but I need to do it inside
>>> LLDB
>>> c++ code in GDBRemoteCommunication.cpp, so when I do a "run" it will
>>> c++ jump
>>> through the correct hoops and connect to the stub under simulation.
>>> 
>>> Is there a good way to call a python script from LLDB c++ code and get
>>> a result back? Or is there a better solution?
>>> 
>> 
>> The the main question is can you run lldb-server in the simulator and have
> the
>> test suite just work? What is stopping you from being able to do that if
> the
>> answer is no?
> 
> I've got the test suite working using the simulator's RSP interface, but the
> next step
> is to exercise the OS stub. And to get to it I have to jump through the
> hoops I talked
> about earlier.
> 
>> It sounds like a real hack if you have to run a python script in
>> ProcessGDBRemote. It sounds like you need to just modify your hexagon
>> simulator platform code to "do the right thing".
> 
> "Do the right thing" in this case involves opening an http connection,
> parsing XML,
> and telling LLDB to connect to the port I get from the XML. The launch is
> done inside
> Process::Launch, which is called from the platform, so I can't do any
> processing
> In the platform.
> 
> Worst case I could do something like 'system("python sim_stub_connect.py")'
> to get the port
> that's being published, if using LLDB's interpreter is not a good idea.

The other way would be to modify your platform code for hexagon such that when you do:

(lldb) platform select hexagon-simulator
(lldb) platform connect <args>
(lldb) file a.out
(lldb) run

It will defer to your platform. Do I understand correctly that you have two ways to launch? One that works with the RSP, but you also want to sometimes connect the OS stub? If so, then I would recommend you modify the <args> to "platform connect" so you can store the information about which type of connection this is and "do the right thing" in the platform code that starts a debug session where you open the http connection, and follow the other steps you must do. Am I missing something?

Greg

> 
>>> Ted
>>> 
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>> 
>>> 
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180404/689986e5/attachment-0001.html>