| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Previously the build would take the presence of the LLVM_CONFIG envvar to
mean that the sanitizers should be built, but this is a common envvar that
could be set for reasons unrelated to the rustc sanitizers.
This commit adds a new envvar RUSTC_BUILD_SANITIZERS and uses it instead.
|
|
|
|
This commit works around the newly-introduced LLVM shared library.
This is needed such that llvm-config run from
librustc_llvm's build script can correctly locate it's own LLVM, not the
one in stage0/lib. The LLVM build system uses the DT_RUNPATH/RUNPATH
header within the llvm-config binary, which we want to use, but because
Cargo always adds the host compiler's "libdir" (stage0/lib in our
case) to the dynamic linker's search path, we weren't properly finding
the freshly-built LLVM in llvm/lib. By restoring the environment
variable setting the search path to what bootstrap sees, the problem is
resolved and librustc_llvm correctly links and finds the appropriate
LLVM.
Several run-make-fulldeps tests are also updated with similar handling.
|
|
|
|
Currently we ship sanitizer libraries as they're built, but these names
unfortunately conflict with the names of the sanitizer libraries
installed on the system. If a crate, for example, links in C code that
wants to use the system sanitizer and the Rust code doesn't use
sanitizers at all, then using `cargo` may accidentally pull in the
Rust-installed sanitizer library due to a conflict in names.
This change is intended to be entirely transparent for Rust users of
sanitizers, it should only hopefully improve our story with other users!
Closes #54134
|
|
This commit is an attempted fix at #50887. It was noticed that on that issue
we're building both x86_64 and i386 versions of libraries, but we only actually
need the x86_64 versions! This hopes that the build race condition exhibited
in #50887 is connected to building both architectures and/or building a lot of
libraries, so this should help us build precisely what we need and no more.
|
|
|
|
ASan and TSan are supported on macOS, and this commit enables their
support.
The sanitizers are always built as *.dylib on Apple platforms, so they
cannot be statically linked into the corresponding `rustc_?san.rlib`. The
dylibs are directly copied to `lib/rustlib/x86_64-apple-darwin/lib/`
instead.
Note, although Xcode also ships with their own copies of ASan/TSan dylibs,
we cannot use them due to version mismatch.
There is a caveat: the sanitizer libraries are linked as @rpath, so the
user needs to additionally pass `-C rpath`:
rustc -Z sanitizer=address -C rpath file.rs
^~~~~~~~
Otherwise there will be a runtime error:
dyld: Library not loaded: @rpath/libclang_rt.asan_osx_dynamic.dylib
Referenced from: /path/to/executable
Reason: image not found
Abort trap: 6
The next commit includes a temporary change in compiler to force the linker
to emit a usable @rpath.
|
|
Add comments
|
|
|
|
|
|
|
|
|
