Skip to content
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

Dependency data not embedded unless inject_dependency_list!() return value is used #9

Closed
Shnatsel opened this issue Aug 1, 2020 · 7 comments
Labels
bug Something isn't working third party Work item for a third-party dependency

Comments

@Shnatsel
Copy link
Member

Shnatsel commented Aug 1, 2020

Dependency information will not be present in the final binary, unless the data returned by auditable::inject_dependency_list!() is actually used somewhere in the binary (printed, put into test::black_box, etc).

This is actually a bug in rustc: rust-lang/rust#47384

@Shnatsel Shnatsel added bug Something isn't working third party Work item for a third-party dependency labels Aug 1, 2020
@Shnatsel Shnatsel changed the title Dependency data not embedded unless version_info() is used Dependency data not embedded unless version_info() is called Aug 1, 2020
@Shnatsel Shnatsel changed the title Dependency data not embedded unless version_info() is called Dependency data not embedded unless inject_dependency_list!() return value is used Aug 2, 2020
@Shnatsel Shnatsel added help wanted Extra attention is needed and removed help wanted Extra attention is needed labels Sep 7, 2020
@nilgoyette
Copy link

I tested this project in our commercial project and there's something I don't understand. You advice to add

println!("{}", COMPRESSED_DEPENDENCY_LIST[0]);

in our main.rs so the variable is used and thus added into the binary strings. This, if course, prints something when the program starts. Obviously I and pretty much everybody don't want anything printed in their console. I can't use nightly either, so the black box trick won't do.

Is there any other tricks to use? Or maybe a better question: should we use this project or the only end goal is to add it into cargo and then we use it?

@Shnatsel
Copy link
Member Author

Is there any other tricks to use?

You can only print it if a certain command-line parameter is passed, like with --help. Anything that uses the data in some way will work.

Or maybe a better question: should we use this project or the only end goal is to add it into cargo and then we use it?

The eventual goal is to add it to Cargo itself, but before that it would be great to see how the approach works in practice and if there is anything we need to change before stabilizing the format. So please use it and provide feedback - it's much easier to act on it here than after it's merged into cargo!

@niklasf
Copy link

niklasf commented Jan 22, 2021

The crate bencher implements black_box in stable Rust like https://docs.rs/bencher/0.1.5/src/bencher/lib.rs.html#590-596, because the optimizer currently does not remove volatile reads. It's a bit sad to resort to unsafe, though:

unsafe {
    // Safety: u8 is Copy.
    ptr::read_volatile(&COMPRESSED_DEPENDENCY_LIST[0]);
}

@mwaitzman
Copy link

The relevant issue (rust-lang/rust#47384) appears to have been quietly fixed, and is now closed as of a week ago

@Shnatsel
Copy link
Member Author

It still isn't usable for ELF - we need #[used(linker)] rather than the current #[used] which is equivalent to #[used(compiler)]. It's difficult to support because only very recent ELF linkers implement the required flags.

I think the way to go is to implement external injection instead, as discussed in #29. I have a prototype in a branch already.

@mwaitzman
Copy link

Oh okay. I was just making sure you were aware that the issue had closed

@Shnatsel
Copy link
Member Author

External injection via cargo auditable is now the default, and it avoids this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working third party Work item for a third-party dependency
Projects
None yet
Development

No branches or pull requests

4 participants