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