Page MenuHomePhabricator

dotest: Add a way for the run_to_* helpers to register dylibs
ClosedPublic

Authored by friss on Nov 12 2019, 10:15 AM.

Details

Summary

To run the testsuite remotely the executable needs to be uploaded to
the target system. The Target takes care of this by default.

When the test uses additional shared libraries, those won't be handled
by default and need to be registered with the target using
test.registerSharedLibrariesWithTarget(target, dylib).

Calling this API requires a target, so it doesn't mesh well with the
run_to_* helpers that we've been advertising as the right way to write
tests.

This patch adds an extra_images argument to all the helpers and does
the registration automatically when running a remote
testsuite. TestWeakSymbols.py was converted to use this new scheme.

Diff Detail

Event Timeline

friss created this revision.Nov 12 2019, 10:15 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 12 2019, 10:15 AM
jingham accepted this revision.Nov 12 2019, 11:05 AM

This is fine.

I wondered a bit about whether it would be generally useful to add the 'dylibs that have to be copied' to the SBLaunchInfo? It has some other platform'y like things. I'm not strongly promoting the idea, just thought I'd float it.

This revision is now accepted and ready to land.Nov 12 2019, 11:05 AM

This is fine.

I wondered a bit about whether it would be generally useful to add the 'dylibs that have to be copied' to the SBLaunchInfo? It has some other platform'y like things. I'm not strongly promoting the idea, just thought I'd float it.

You can currently do this by setting the platform file spec for a SBModule. If that is set, then the target will upload the module to that path. The main executable always goes to the remote working directory if its platform file spec isn't set, but any module can set this manually. The register shared libraries code sets the platform path.

This is fine.

I wondered a bit about whether it would be generally useful to add the 'dylibs that have to be copied' to the SBLaunchInfo? It has some other platform'y like things. I'm not strongly promoting the idea, just thought I'd float it.

You can currently do this by setting the platform file spec for a SBModule. If that is set, then the target will upload the module to that path. The main executable always goes to the remote working directory if its platform file spec isn't set, but any module can set this manually. The register shared libraries code sets the platform path.

I don't think that this would help in Fred's case, since he needs to pass something that will work to the API that CREATES the target, so he doesn't really have an SBModule for the library yet. OTOH, since there's another way to do this that works more generally, then that make adding it to the SBLaunchInfo seem redundant...

This revision was automatically updated to reflect the committed changes.