> On Apr 3, 2018, at 4:30 PM, Ted Woodward <ted.woodw...@codeaurora.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.
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 <args> (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 <args> 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 > >>> 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 <mailto:lldb-dev@lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> <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
