New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No coverage for cdylib crate called from C/C++ executables #1156
Comments
One potential for debugging is using the CLI tools I did in https://github.com/xd009642/llvm-profparser to see how the profraw files and binary look in terms of paths etc (or the relevant llvm tools). |
Ok, I think I found the issue! Using the actual test executable as an object file makes the code miss a lot of executed functions:
But by forcing the code to use the shared library as an object file, it is able to report coverage for the expected functions
I guess this makes sense since the test executable never loads this shared library. Instead it execute I guess the simplest thing to do might be to use the tools from llvm-profparser manually to extract coverage information, and use that in CI. Do you think it would make sense to add an option to cargo tarpaulin to manually add other object files to the list that ends up loaded in the CoverageMapping? tarpaulin/src/statemachine/instrumented.rs Line 134 in 57f2a75
|
sorry for late response, I do think that feature makes sense and I'd be happy to add it or accept a PR to do so 😄 EDIT: working on it now, so no need for a PR |
Okay I've implemented this and I can see it works (output at bottom). I'll just be making a PR and merging it once everything is shown to pass All the increases in coverage show difference before me doing it and now with the new Command ran:
|
Thanks a lot, that's great!! |
Any reason for the call to Line 39 in f92c1bb
It fails on CI, since the shared library does not exist yet when the |
Generally just to get an absolute path, because they're needed in various replaces (reports, coverage collection) and relative paths are pernicious with workspaces and hard to keep track of for normalising at the end. However, that canonicalise is for the Line 129 in f92c1bb
It might be possible to remove it some how, or maybe moving the join to the end after the unwrap would fix it. |
@Luthaf if you try out the |
Thank you so much for the quick fix! I needed another small change, which I put in #1225. With that, I'm able to collect coverage for my project. |
Cool I'll look at the PR and merge etc and look to get a release out once I'm done with work today 👍 |
And this is released now |
Describe the bug
I have a project (https://github.com/Luthaf/rascaline/, coverage branch, PR with CI is Luthaf/rascaline#126) which is built as both a rust crate (tarpaulin works great here, thanks a lot!) and exports a C API through a cdylib crate (
rascaline-c-api
). The C API is then used to create a C++ (and Python) interface for the code.The C and C++ API are tested as a normal C/C++ project, using CMake to first build the rust code, and then build C and C++ test executables. I made sure to pass the right flags to rustc (setting
RUSTFLAGS="-Cdebuginfo=2 --cfg=tarpaulin -Cinstrument-coverage -Clink-dead-code"
) when building the rust shared library.The LLVM-based coverage instrumentation seems to work fine, generating
.profraw
files (I added a small patch in Luthaf@c67eb17 since the profraw files are generated inside a different directory), but then no coverage is reported for the c-api crate at all. I added a handful ofdbg!
inside cargo-tarpaulin and llvm-profparser, and as far as I understand the code it seems that the profraw files contain at least some coverage data.To Reproduce
git clone https://github.com/Luthaf/rascaline cd rascaline git checkout coverage cargo tarpaulin --all-features --workspace --engine=llvm --test=c-api-tests --skip-clean --verbose
Here is the output I get: tarpaulin-rascaline.txt
I'm wondering if there could be an issue with file name parsing or something like this, since all the path shown are relative to the
rascaline-c-api
crate, and not the root of the repository/root of the cargo workspace.If you have a couple of pointer/thinks I could look for, I'm happy to continue debugging this and send a PR once it is fixed.
Expected behavior
Using an instrumented shared library from C or C++ should be able to collect and report coverage on the C API implementation in rust.
The text was updated successfully, but these errors were encountered: