compiler-builtins
compiler-builtins copied to clipboard
rust-lang
`__clear_cache` missing for `aarch64-linux-android`
Attempting to dlopen my shared library on an android device results in it being unable to find the __clear_cache symbol. This is needed for my project.
It is needed for me to build core for bbqsrc/cargo-ndk#22.
__clear_cache is not used by Rust though. If it is used from C code then the C code should link to the clang_rt library which provides symbols used by Clang. Or are you calling it manually yourself?
It is used from C code which is being compiled with the cc crate. I thought clang would automatically link to clang_rt? This issue is kind of hazy because of all the combinations of NDK versions and workarounds.
Some background that isn't entirely in the scope of this repository, but explains the situation I'm in:
NDK r23 introduced a change that replaced libgcc with libunwind making it impossible to link the prebuilt std crate as it is built with an older NDK version using libgcc. There is a way to use the prebuilt std on newer NDK versions with this workaround, but it still results in the __clear_cache problem.
I found that compiling with NDK r22 with or without -Zbuild-std resulted in a fully working binary. Because of this, I've ended up downgrading my NDK to this version as it works without issue.
@rust-lang/compiler @rust-lang/libs
What exactly should the role of compiler-builtins be here? There are essentially 2 options:
compiler-builtinsprovides only the symbols that are used by rustc-generated code.compiler-builtinsprovides the symbols needed for both C and Rust code (i.e. it is a superset of libgcc/compiler_rt).
Currently the status quo is an awkward mix of the above. We cover the symbols used by LLVM for rustc-generated code, but also symbols that are only used by C code (such as the long double libcall used by musl on aarch64).
What exactly should the role of compiler-builtins be here? There are essentially 2 options:
What are the trade-offs between these two options? Are there performance or codegen size costs to option 2?
There are no performance or size costs to option 2: the linker will only include functions that are actually used.
It's more of a maintenance concern: if we need to provide symbols needed by C code then we need to compile external C code as part of compiler-builtins (we already do it for some functions, but it is optional). In particular, there is no way to write functions using long double in Rust since the relevant types don't exist in the language.
If you look at the README for this crate, you will see all the functions that we don't include for various reasons, mainly that rustc/LLVM isn't emitting calls to them. We would need to either provide Rust implementations for all of these or build the C version from LLVM's compiler-rt.
I see, and we already do a mix of both, which seems functionally equivalent to an incremental version of option 2.
@StackDoubleFlow, if we didn't add __clear_cache would you be able to fix this by manually linking in clang_rt?
We already do a mix of both by necessity, for example to support uses of long double in the musl libc that we ship as part of the aarch64-unknown-linux-musl target.
@yaahc I found that passing --rtlib=compiler-rt as a compile flag in cc and as a linker flag had no effect.
If I wanted to use __clear_cache from rust code, would I be able to do that?
@StackDoubleFlow Did you find a solution to this issue? I am only able to work around it by specifying the equivalent of -L <dir of compiler-rt> -lclang_rt.builtins-aarch64-android via a build.rs file.
