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

Wed Apr 4 05:14:34 PDT 2018

The easiest solution may be turn your python script into a full-fledged
forwarder (instead of just a port-number-finder). Then, from lldb's point
of view it would just be launching a debugserver (that happens to be
implemented in python) and communicating with it. And all the forwarding
magic would happen inside your script.

pl

On Wed, 4 Apr 2018 at 00:30, Ted Woodward via lldb-dev <
lldb-dev at lists.llvm.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.
>
> > > 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
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> 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/1b02b57f/attachment-0001.html>