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@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:clayb...@gmail.com] > > Sent: Tuesday, April 03, 2018 5:19 PM > > To: Ted Woodward <ted.woodw...@codeaurora.org> > > Cc: lldb-dev@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- > > d...@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@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
