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

[Ted Woodward via lldb-dev]

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