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
