Unneeded PDB files generated for proc_macro and build script.

[crlf0710]

Problem

I'm using 1.72.0 toolchain now, but it seems debuginfo is still generated. I created a blank binary crate(dummy) and added the ref-cast = "1" dependency. Now when building with cargo build --release, there's four pdb files generated:

• dummy.pdb which may or may not be necessary.
• ref_cast_impl-76ca1ba5cac1102e.pdb which is for the proc-macro.
• build_script_build-6a4abe8b3691b295.pdb which is for the ref-cast build.rs script
• build_script_build-9201a10d7023ee91.pdb which is for the proc-macro2 build.rs script

[lqd]

There are more details in the associated discussion on zulip: this is debuginfo from the libstd and "not from the crates themselves".

That is, cargo correctly doesn't call rustc with -C debuginfo here (there's no unit graph sharing build deps debuginfo weakening to worry about, since this is in --release). As far as I can tell the only way to currently remove libstd's debuginfo is to strip it away, but that's probably a rustc concern rather cargo's IMO.

[hanna-kruppe]

Like some people involved in the Zulip discussion, I would have expected -Cstrip=debuginfo to resolve this. Nowadays Cargo passes that by default in release builds (#13257). However, when I test it locally I see the build script being built with that flag but still getting PDB outputs. Even an ordinary bin target (cargo new --bin test-pdb) produces a PDB file despite Cargo passing -Cstrip=debuginfo, so it's not some weirdness related to profile.release.build-override. Does -Cstrip=debuginfo even work on Windows targets?

[ChrisDenton]

Does -Cstrip=debuginfo even work on Windows targets?

It's intentionally a no-op. PDB files are external to the binary so there's no debug information to strip from the binary itself. There's some discussion here and here.

You can pass the /DEBUG:NONE flag to the linker to completely disable generation of debug info (including symbols).

[hanna-kruppe]

If I understand correctly from a quick skim:

• Having a PDB file is needed to have any symbols in backtraces, so it's undesirable for -Cstrip=debuginfo to drop the PDB entirely
• There's been discussions to have -Csplit-debuginfo=off mean "don't generate a PDB" but it seems this wasn't implemented (or I'm holding it wrong)
• There's no such thing as pruning debuginfo from existing rlibs before linking to make the PDB file contain only the bare minimum needed for useful backtraces

I don't think there's a way for Cargo profiles to add linker flags, but split-debuginfo can be set. So implementing the proposal for -Csplit-debuginfo=off to mean /DEBUG:NONE would offer a way to address this issue. An entirely new rustc flag (or new value for existing flags) would work as well, but then Cargo also needs to add support for setting that flag in profiles, which is not guaranteed.

[weihanglo]

Cargo also doesn't know about the actual linker being used, so it may be a bit risky for Cargo to assume profile.split-debuginfo=off implies -C link-arg=/DEBUG:NONE.

[hanna-kruppe]

Cargo should definitely leave this to rustc (i.e., rustc itself could modify its link.exe invocation based on -Cstrip-debuginfo). But #10271 could let users opt into linker flags on a per profile basis (unlike the big hammer of setting flags for all builds in .cargo/config.toml) if they're willing to assume that they'll be linked by link.exe. Though portable projects would also need a way to vary the profile-rustflags by rustc target tuple.

[ChrisDenton]

Not generating any debug information (not even symbols) is itself a very heavy hammer. While the compile time improvements might make the trade-off worth it for proc-macros and build scripts, there needs to be an opt-out for when debugging is necessary. Whereas for actual final binaries it should be something you have to opt-in to rather than opt-out.

This suggests to me that there may need to be a special profile for intermediary build artefacts that's independent of the final output artefacts. Or at least some way to configure them independently.

[hanna-kruppe]

There's already a way to override profile settings for build dependencies, that seems to mostly fit the bill?

[ChrisDenton]

Yes that would work.