Add link seam example w/ Starboard proxy

[hlwarriner]

This is an implementation of an idea raised by jfoks@ in a comment in go/starboard-test-doubles. The Starboard proxy can be used to register/unregister a test double to be used in place of a real Starboard API; the test double can be used by the code under test, and the platform's real implementation can be used by surrounding code in the loader, googletest, etc.

This PR is just uploaded to gather feedback and won't be merged.

b/36360851

Change-Id: I786759517d954aae34707830be8efc962c956b2b

[hlwarriner]

@y4vor @jellefoks, can you please mostly focus on the API and implementation of test double (un)registration?

The failing checks can be ignored, this is just a prototype and is far from a mergeable state.

You can run the unit test on linux (modular) with:

export MODULAR_BUILD=1

gn gen out/linux-x64x11_devel --args='target_platform="linux-x64x11" build_type="devel" build_with_separate_cobalt_toolchain=true use_asan=false'

ninja -C out/linux-x64x11_devel all -j 100

python3 starboard/tools/testing/test_runner.py --platform linux-x64x11 --config devel -t utils_test

Note that asan needs to be disabled - I'm still looking into why it doesn't work with asan enabled.

[jellefoks]

Spoke offline.

[hlwarriner]

Spoke offline.

As discussed, as a next step I'll update this PR to abstract the demand loading piece. With this Starboard Proxy approach, every platform will need to be able to dynamically load its Starboard shared library and look up symbols from it - but some platforms may implement this with utilities other than dlopen/dlsym.

[hlwarriner]

Spoke offline.

As discussed, as a next step I'll update this PR to abstract the demand loading piece. With this Starboard Proxy approach, every platform will need to be able to dynamically load its Starboard shared library and look up symbols from it - but some platforms may implement this with utilities other than dlopen/dlsym.

Ok, I uploaded a second commit that uses a Starboard extension to abstract dlopen/dlsym/dlclose and provides an implementation for POSIX platforms: just dlopen/dlsym/dlclose. This was just a naive first attempt at the extension's API, and it will likely need some changes (more general, support for error checking, ...).

There's also one limitation: because the proxy now uses SbSystemGetExtension to get the Runtime Linking extension, the proxy can't also define SbSystemGetExtension in order to enable this Starboard API to be mocked/stubbed in tests - if it did, the proxy's own implementation would shadow the real Starboard implementation, and the proxy wouldn't be able to access the Runtime Linking extension. I have a couple ideas to overcome this limitation and will upload another commit soon.

[hlwarriner]

Spoke offline.

As discussed, as a next step I'll update this PR to abstract the demand loading piece. With this Starboard Proxy approach, every platform will need to be able to dynamically load its Starboard shared library and look up symbols from it - but some platforms may implement this with utilities other than dlopen/dlsym.

Ok, I uploaded a second commit that uses a Starboard extension to abstract dlopen/dlsym/dlclose and provides an implementation for POSIX platforms: just dlopen/dlsym/dlclose. This was just a naive first attempt at the extension's API, and it will likely need some changes (more general, support for error checking, ...).

There's also one limitation: because the proxy now uses SbSystemGetExtension to get the Runtime Linking extension, the proxy can't also define SbSystemGetExtension in order to enable this Starboard API to be mocked/stubbed in tests - if it did, the proxy's own implementation would shadow the real Starboard implementation, and the proxy wouldn't be able to access the Runtime Linking extension. I have a couple ideas to overcome this limitation and will upload another commit soon.

I uploaded a new commit that solves this by adding a new SbSystemGetRealExtension Starboard API which, unlike SbSystemGetExtension, should never be stubbed/mocked.