x86_64-pc-windows-msvc target not producing PDB for large project

[Luminoth]

Problem

I have a large project that I'm building on Windows for the x86_64-pc-windows-msvc target that I am expecting to have a PDB produced for, but am not seeing that in either the target\release\deps folder or the target\release folder. I have created a separate smaller test project that does not have this issue.

Steps

I'm honestly not sure what steps are necessary. For what it's worth, this is my large project's Cargo.toml (dependencies removed to reduce clutter):

[package]
name = "large-app"
version = "0.1.0"
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[[bin]]
name = "large-app"
path = "src/main.rs"

[profile.release]
debug = true

# turn off optimizations for build scripts and proc macros
[profile.release.build-override]
opt-level = 0

[dependencies]
...

And this is the Cargo.toml from my small, fresh application:

[package]
name = "tester"
version = "0.1.0"
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

[profile.release]
debug = true

[profile.release.build-override]
opt-level = 0

Notes

Output of cargo version: cargo 1.42.0 (8633429 2020-01-31)
rustc version: rustc 1.42.0 (b8cedc004 2020-03-09)

I'm not sure what else would be useful to see here. The same thing is occurring with nightly cargo 1.44.0-nightly (74e3a7d 2020-04-13).

[ehuss]

You might want to run cargo with the -v flag and make sure it is passing -C debuginfo=2 to rustc.

Another thing to check is to see if it is passing debug to the linker. On nightly, run: cargo +nightly rustc --bin mybin -- -Zprint-link-args and make sure it is passing /DEBUG to link.exe.

[Luminoth]

I do see -C debuginfo=2 being passed in to rustc for my binary. Running the nightly cargo command I do see /DEBUG in the set of options passed in to link.exe.

[alexcrichton]

One behavior I've seen in the past is that the PDB file is created asynchronously from link.exe, not synchronously during compilation. With Cargo/rustup though all subprocesses are killed after Cargo returns, primarily to thwart just this since it affects sequential/parallel compilations.

Unfortunately I don't know of a great way to test this though. If you can build from source you can comment out this code and then make sure to run Cargo directly instead of Cargo-through-rustup, and see if that fixes the issue for you

[alexcrichton]

er no scratch that, I forget that we changed the logic at some point that successful builds don't kill anything, so disregard me!

[Luminoth]

Oh whoa, so I went back to double check since you mentioned it's created by an async process and it looks like it might be named wrong. In my target\release\deps I have my binary large-app.exe and also a pdb: large_app.pdb.

So I went back to another small test app with this Cargo.toml:

[package]
name = "tester-test"
version = "0.1.0"
edition = "2018"

[[bin]]
name = "tester-test"
path = "src/main.rs"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

[profile.release]
debug = true

[profile.release.build-override]
opt-level = 0

and low and behold, I have target\release\deps\tester_test.pdb and no PDB in target\release. It seems like whatever is causing that renaming is interfering with cargo being able to copy it to the final target dir.

[alexcrichton]

I may also be misremembering, I'm not certain that production of the pdb happens asynchronously myself. If it does, though, then Cargo might miss the production to rename it, since it may be produced after Cargo finishes.

[Luminoth]

When I have a free minute, I'll do a clean build and watch for it to show up. If it does so after cargo finishes then I'll just have our larger build system find it and copy it. If it does show up before cargo finishes, is that a buggable thing I should post back here with?

EDIT - Oh, but the same thing happens on my small test (just adding a hyphen in the name breaks it). It actually seems like cargo just doesn't know that the PDB is the wrong name when it goes to copy it.

[alexcrichton]

Ah ok looks like you're right in that case, I think this is probably a bug in cargo's handling of - vs _ somewhere!

[ehuss]

Posted a fix at #8123.