class LdStartupInProcessTests
Defined at line 32 of file ../../sdk/lib/ld/test/ld-startup-in-process-tests-zircon.h
On Fuchsia this means packing a message on the bootstrap channel. The entry
point receives the bootstrap channel (zx_handle_t) and the base address of
the vDSO.
Public Members
static basic_string_view kTestExecutableSuffixPublic Methods
void Init (std::initializer_list<std::string_view> args, std::initializer_list<std::string_view> env)Defined at line 115 of file ../../sdk/lib/ld/test/ld-startup-in-process-tests-posix.cc
void Load (std::string_view executable_name)Defined at line 121 of file ../../sdk/lib/ld/test/ld-startup-in-process-tests-posix.cc
int64_t Run ()Defined at line 204 of file ../../sdk/lib/ld/test/ld-startup-in-process-tests-posix.cc
void Load (std::string_view executable_name, std::optional<std::string_view> expected_config)Defined at line 61 of file ../../sdk/lib/ld/test/ld-startup-in-process-tests-zircon.cc
void ExpectLog (std::string_view expected_log)The loaded code is just writing to STDERR_FILENO in the same process.
There's no way to install e.g. a pipe end as STDERR_FILENO for the loaded
code without also hijacking stderr for the test harness itself, which seems
a bit dodgy even if the original file descriptor were saved and dup2'd back
after the test succeeds. In the long run, most cases where the real dynamic
linker would emit any diagnostics are when it would then crash the process,
so those cases will only get tested via spawning a new process, not
in-process tests.
Defined at line 289 of file ../../sdk/lib/ld/test/ld-startup-in-process-tests-posix.cc
void ~LdStartupInProcessTests ()Defined at line 212 of file ../../sdk/lib/ld/test/ld-startup-in-process-tests-posix.cc
std::pair<int64_t, zx::channel> RunWithCustomBootstrap ()Defined at line 110 of file ../../sdk/lib/ld/test/ld-startup-in-process-tests-zircon.cc