This is an archive of the discontinued LLVM Phabricator instance.

Refactor GdbRemote test cases to support remote platforms
ClosedPublic

Authored by tberghammer on Mar 10 2015, 7:18 AM.

Details

Summary

Refactor GdbRemote test cases to support remote platforms

Previously these test cases execute lldb-server on the host and run the tests against it even if a remote platform was specified. With this CL these tests always test the communication with an lldb-server instance running on the target.

Diff Detail

Repository
rL LLVM

Event Timeline

tberghammer retitled this revision from to Refactor GdbRemote test cases to support remote platforms.
tberghammer updated this object.
tberghammer edited the test plan for this revision. (Show Details)
tberghammer added reviewers: vharron, clayborg.
tberghammer added a subscriber: Unknown Object (MLST).
clayborg edited edge metadata.Mar 10 2015, 1:27 PM

You shouldn't ever have to call SBPlatform::Install() manually unless you just want to run a process remotely without debugging it. Is this what you are trying to do? Install something so that lldb-server can be used? If so ignore what I am saying below.

If you are trying to just debug something remotely, you should be able to connect to the remote platform and it will of course launch lldb-server for you and you should follow the rules below:

The idea with the current SBPlatform and debugging a remote process is:
1 - The main executable will always be installed in the remote working directory unless you set the remote install file spec (see below)
2 - Get a SBModule you want to have uploaded from your target by either finding it, or adding it to the target using SBTarget::AddModule(...) and then call SBModule::SetRemoteInstallFileSpec (lldb::SBFileSpec &file) on any module that you want to ensure is installed by giving the remote path.
3 - When the process is launched, it will iterate through all modules in a target and check for a remote install file spec and anything that has it will be installed to the desired location, and of course the main executable always gets installed. This happens in:

Error
Target::Install (ProcessLaunchInfo *launch_info)

So check your code to make sure it isn't the above case where you just want to remote debug a process and where there is already code that can do the auto-install stuff for you.

As far as I know spawnSubprocess() generally used in test cases where lldb (LLGS) attach to an already running process, where the Install is necessary.

In this patch I address issues related to test cases testing the gdb protocol of LLGS with launching it on the target and then connecting to it with a socket. I use the spawnSubprocess() to start LLGS (in gdbserver mode) before connecting to it from python.

The option to disable the installation of the specified executable by spawSubprocess is required, because I have to start the same process as lldb-platform (actually lldb-server) and it can be too big to transfer it over to the remote target (~35 MB release, ~850 MB debug).

tberghammer added inline comments.Mar 10 2015, 3:34 PM
test/tools/lldb-server/gdbremote_testcase.py
363 ↗(On Diff #21575)

SBPlatform::Install used here also, but I think it is impossible to avoid, because these tests are testing LLGS in a lower level with sending packets directly to it.
The logic you mentioned is executed only when we do a "run" or a "process launch" command in lldb what isn't happening here. The inferior is launched with sending an $A packet directly to LLGS from python with skipping the logic surrounding it in lldb.

clayborg accepted this revision.Mar 10 2015, 3:56 PM
clayborg edited edge metadata.

Thanks for the explanation. Looks good.

This revision is now accepted and ready to land.Mar 10 2015, 3:56 PM
This revision was automatically updated to reflect the committed changes.