Can I call a python script from LLDB c++ code?

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

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 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?

Ted

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...

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 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?

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".

Responses inline

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

Responses inline


Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

From: Greg Clayton [mailto:clayborg@gmail.com]
Sent: Tuesday, April 03, 2018 5:19 PM
To: Ted Woodward <ted.woodward@codeaurora.org>
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Can I call a python script from LLDB c++ code?

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
(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 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