Repository navigation
Code coverage does not work on armv7-unknown-linux-gnueabihf due to missing profiler_builtins #79640
Description
Activity
My guess is the version of
rustcyou are compiling with was built withoutprofiler = trueset in its build configuration (e.g.,config.toml).Related in the sense that both issues report that the build of the compiler for their target platforms does not set "profiler = true".
Yes, the default is "profiler = false", but various pre-built distros enable "profiler = true". Some don't. I don't know who makes those decisions, whether we should change this to enable "profiler = true" by default in the future, and/or whether the profiler_builtins library works or not for some platforms.
Is there any update on this? Is this simply a matter of adding
--enable-profilerto the Dockerfile, or are there other pieces missing too?@rich-g I think this is something pretty low-level to be enabled first inside the compiled rust docker image, nothing that can just be activated via that parameter. I will try to re-check on the upcoming weekend to see if there has something changed silently.
Reacted by Richard Gura@rich-g Nope, still the same issue. Retried on a fresh install of the whole system (Bullseye-based raspbianOS ... whatever its called) and got the same output:
root@ae1e55809c68:/rust-project# cargo +nightly test --verbose Compiling rust-project v0.1.0 (/rust-project) Running `rustc --crate-name rust_project --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --test -C metadata=0d091f013ad5ec96 -C extra-filename=-0d091f013ad5ec96 --out-dir /rust-project/target/debug/deps -L dependency=/rust-project/target/debug/deps -Zprofile -Ccodegen-units=1 -Copt-level=0 -Clink-dead-code -Coverflow-checks=off -Zpanic_abort_tests -Cpanic=abort` error[E0463]: can't find crate for `profiler_builtins` | = note: the compiler may have been built without the profiler runtime For more information about this error, try `rustc --explain E0463`. error: could not compile `rust-project` due to previous error Caused by: process didn't exit successfully: `rustc --crate-name rust_project --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --test -C metadata=0d091f013ad5ec96 -C extra-filename=-0d091f013ad5ec96 --out-dir /rust-project/target/debug/deps -L dependency=/rust-project/target/debug/deps -Zprofile -Ccodegen-units=1 -Copt-level=0 -Clink-dead-code -Coverflow-checks=off -Zpanic_abort_tests -Cpanic=abort` (exit status: 1) root@ae1e55809c68:/rust-project#versions:
root@ae1e55809c68:/rust-project# rustc --version --verbose rustc 1.60.0 (7737e0b5c 2022-04-04) binary: rustc commit-hash: 7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c commit-date: 2022-04-04 host: armv7-unknown-linux-gnueabihf release: 1.60.0 LLVM version: 14.0.0 root@ae1e55809c68:/rust-project# rustc +nightly --version --verbose rustc 1.62.0-nightly (30f386087 2022-05-05) binary: rustc commit-hash: 30f386087564243ab88a93c984c265290a31580b commit-date: 2022-05-05 host: armv7-unknown-linux-gnueabihf release: 1.62.0-nightly LLVM version: 14.0.1EDIT: just to point out, the used rust comes from the docker-container, not the hosting OS
Potential duplicate of #79556?
@clarfonthey similar but no duplicate, because the other issue targets MUSL, this is ARMv7-specific 😸
Right, but the root cause appears to be an issue with the releases provided for tier 2 targets, which affects both.
This already got suggested here: #79640 (comment)
All it comes down to "profiler_builtins" not being present. If both issues are having the same root cause, thats okay, but as every target is configured differently (like already mentioned here: #79640 (comment)), so I do not see a duplicate here. #79556 is specificly targeting MUSL, this is non-MUSL and includes an easy reproducable example.
- added a commit that references this issue
on Aug 15, 2022 Is there a way to activate it when building the compiler manually as a temporary solution?
Is there a way to activate it when building the compiler manually as a temporary solution?
Try building with
--enable-profiler(see PR #124829). if you get linker errors, try linking with'-latomicas described in #112313 (comment).- added a commit that references this issue
on May 12, 2024 I verified that with today's Rust Nightly, code coverage is working. See briansmith/ring#2056. This target "just works"; it doesn't require forcing
-latomiclike powerpc-unknown-linux-gnu.Reacted by JoelImgu, Danny Althoff and Suraj
I am new to the Rust ecosystem, but as part of my own learning curve, I wanted to create a small personal project which includes test coverage executed on my raspberry pi server.
My setup contains a self-hosted Gitlab-instance (which runs inside docker) running on a 32-bit based Raspbian on my Raspberry Pi 4 (with 8gb RAM). After some hours of trying to get grcov working I tried to reproduce my problems, and found out, that
profiler_builtinsare missing for armv7-unknown-linux-gnueabihf.I opened up an issue on the GRCOV-project (mozilla/grcov#508), because I first thought I was missing some important instruction to set up my system. It now seems to me that the package provided via
rustupdoes not include the required crates/libs to make it work to have code coverage being analysed.Steps to reproduce
rust-projectcontaining a normal project (inited viacargo init)Content of
main.rs:Dockerfileaside of that folder:docker build -t rust-grcov-raspberry-bug:latest .docker run --rm -ti rust-grcov-raspberry-bug:latestResult on Raspberry Pi 4 (32bit arm)
Result on local Windows 10 using docker-desktop (64bit amd64)