pgo: -Cprofile-use can't find file

[matthiaskrgr]

git clone https://github.com/matthiaskrgr/cargo-cache
cd cargo-cache
RUSTFLAGS="-Cprofile-generate=target/pgodata" cargo build --release
./target/release/cargo-cache
./target/release/cargo-cache
./target/release/cargo-cache q hello
./target/release/cargo-cache r
./target/release/cargo-cache --top-cache-items 10
llvm-profdata merge -o target/merged.profdata ./target/pgodata/
file target/merged.profdata  
# target/merged.profdata: LLVM indexed profile data, version 5
RUSTFLAGS="-Cprofile-use=target/merged.profdata" cargo build --release  -j 1

   Compiling serde v1.0.98
error: File `target/merged.profdata` passed to `-C profile-use` does not exist.

error: aborting due to previous error

error: Could not compile `serde`.

To learn more, run the command again with --verbose.

The file is definitely there, but for some reason it is not found??

rustc 1.38.0-nightly (c43d03a19 2019-08-14)

[jonas-schievink]

Does it work when specifying an absolute path? Maybe Cargo runs rustc in an unexpected working dir.

[matthiaskrgr]

Oh that works, weird...

[matthiaskrgr]

I would suggest the following: if the path is absolute and works, use it. If the path is relative but exists, print an error but suggest using its absolute path/form. Otherwise throw an error as before.

[jonas-schievink]

Nit: The error message should also be changed to start with a lowercase letter (so "file" instead of "File")

[matthiaskrgr]

It is also strange that -Cprofile-generate works with relative paths but -Cprofile-use does not.. Maybe that should be consistent somehow...

[jonas-schievink]

I believe -Cprofile-generate will just write the relative dir into the binary, so wherever you run the binary it will write to that path (ie. rustc never needs to do any IO with that path). If you run rustc by hand relative paths should work fine with -Cprofile-use though.

Oh and the rustc book mentions this:

It is recommended to use absolute paths for the argument of -Cprofile-generate and -Cprofile-use. Cargo can invoke rustc with varying working directories, meaning that rustc will not be able to find the supplied .profdata file. With absolute paths this is not an issue.

[nazar-pc]

I get an error with absolute path instead of some reason:

``` error: failed to run `rustc` to learn about target-specific information Caused by: process didn't exit successfully: `rustc - --crate-name ___ --print=file-names -Cprofile-use=/tmp/pgo-data/merged.profdata --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg` (exit status: 1) --- stdout ___ lib___.rlib lib___.so lib___.so lib___.a lib___.so /home/nazar-pc/.rustup/toolchains/nightly-2023-04-02-x86_64-unknown-linux-gnu off packed unpacked ___ debug_assertions panic="unwind" proc_macro target_abi="" target_arch="x86_64" target_endian="little" target_env="gnu" target_family="unix" target_feature="fxsr" target_feature="sse" target_feature="sse2" target_has_atomic target_has_atomic="16" target_has_atomic="32" target_has_atomic="64" target_has_atomic="8" target_has_atomic="ptr" target_has_atomic_equal_alignment="16" target_has_atomic_equal_alignment="32" target_has_atomic_equal_alignment="64" target_has_atomic_equal_alignment="8" target_has_atomic_equal_alignment="ptr" target_has_atomic_load_store target_has_atomic_load_store="16" target_has_atomic_load_store="32" target_has_atomic_load_store="64" target_has_atomic_load_store="8" target_has_atomic_load_store="ptr" target_os="linux" target_pointer_width="64" target_thread_local target_vendor="unknown" unix --- stderr error: file `/tmp/pgo-data/merged.profdata` passed to `-C profile-use` does not exist. error: aborting due to previous error ```

The file certainly exists :confused:

[caizixian]

Possibly related #115344