868bdde25b
Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to "llvm.used". The volatile load in the main shim is retained because "llvm.used", which translates to SHF_GNU_RETAIN on ELF targets, requires a reasonably recent linker; emitting the volatile load ensures compatibility with older linkers, at least when libstd is used. Pretty printers in dylib dependencies are now emitted by the main crate instead of the dylib; apart from matching how rlibs are handled, this approach has the advantage that `omit_gdb_pretty_printer_section` keeps working with dylib dependencies.
The run-make test suite
The run-make test suite contains tests which are the most flexible out of all the rust-lang/rust test suites. run-make tests can basically contain arbitrary code, and are supported by the run_make_support library.
Infrastructure
A run-make test is a test recipe source file rmake.rs accompanied by its parent directory (e.g. tests/run-make/foo/rmake.rs is the foo run-make test).
The implementation for collecting and building the rmake.rs recipes are in src/tools/compiletest/src/runtest.rs, in run_rmake_test.
The setup for the rmake.rs can be summarized as a 3-stage process:
-
First, we build the
run_make_supportlibrary in bootstrap as a tool lib. -
Then, we compile the
rmake.rs"recipe" linking the support library and its dependencies in, and provide a bunch of env vars. We setup a directory structure withinbuild/<target>/test/run-make/<test-name>/ rmake.exe # recipe binary rmake_out/ # sources from test sources copied overand copy non-
rmake.rsinput support files over tormake_out/. The support library is made available as an extern prelude. -
Finally, we run the recipe binary and set
rmake_out/as the working directory.