Big file size regression on Windows

[BlaCoiso]

Binary sizes on the latest nightlies are significantly larger than on stable and some previous nightly versions. This is caused by some extra sections in the binary and also an increase in the text and data sections
Stable (1.62.0):

nth paddr          size vaddr          vsize perm name
――――――――――――――――――――――――――――――――――――――――――――――――――――――
0   0x00000400  0x19e00 0x140001000  0x1a000 -r-x .text
1   0x0001a200   0x7600 0x14001b000   0x8000 -r-- .rdata
2   0x00021800    0x200 0x140023000   0x1000 -rw- .data
3   0x00021a00   0x1200 0x140024000   0x2000 -r-- .pdata
4   0x00022c00    0x400 0x140026000   0x1000 -r-- .reloc

Nightly (1.64.0-nightly c396bb3):

nth paddr          size vaddr          vsize perm name
――――――――――――――――――――――――――――――――――――――――――――――――――――――
0   0x00000400  0x7d200 0x140001000  0x7e000 -r-x .text
1   0x0007d600  0x29c00 0x14007f000  0x2a000 -r-- .rdata
2   0x000a7200    0x200 0x1400a9000   0x1000 -rw- .data
3   0x000a7400   0x5c00 0x1400aa000   0x6000 -r-- .pdata
4   0x000ad000    0xc00 0x1400b0000   0x1000 -r-- .debug_a
5   0x000adc00  0x9d000 0x1400b1000  0x9d000 -r-- .debug_i
6   0x0014ac00   0x9000 0x14014e000   0x9000 -r-- .debug_a_1
7   0x00153c00  0x68c00 0x140157000  0x69000 -r-- .debug_r
8   0x001bc800  0xe8e00 0x1401c0000  0xe9000 -r-- .debug_s
9   0x002a5600  0x5a000 0x1402a9000  0x5a000 -r-- .debug_p
10  0x002ff600    0x200 0x140303000   0x1000 -r-- .debug_p_1
11  0x002ff800  0x3a200 0x140304000  0x3b000 -r-- .debug_l
12  0x00339a00  0x21400 0x14033f000  0x22000 -r-- .reloc

Code

I tried this code:

fn main() {}

I expected to see this happen: small binary size (143 360 bytes on 1.62.0)

Instead, this happened: extremely large binary size (3 517 952 bytes)

Version it worked on

It most recently worked on: Rust 1.64.0 (nightly) ddcbba0

Version with regression

rustc --version --verbose:

rustc 1.64.0-nightly (c396bb3b8 2022-07-10)
binary: rustc
commit-hash: c396bb3b8a16b1f2762b7c6078dc3e023f6a2493
commit-date: 2022-07-10
host: x86_64-pc-windows-msvc
release: 1.64.0-nightly
LLVM version: 14.0.6

[ehuss]

This seems to be due to #98350, cc @pcwalton.

[eddyb]

How was this built? cargo build (i.e. without --release) would enable debuginfo, but plain rustc hello.rs wouldn't.

My best guess (and why I'm asking the above) is that you already have a .pdb next to the .exe, but #98350 caused you to also have DWARF debuginfo in the .exe (and that part is the regression).

EDIT: turns out it's the standard library, I forgot we compile it w/ debuginfo until #99143 (comment)

[BlaCoiso]

How was this built? cargo build (i.e. without --release) would enable debuginfo, but plain rustc hello.rs wouldn't.

This was built with rustc +nightly main.rs -C opt-level=3 -C target-cpu=native, although the same thing happens with cargo +nightly build --release

[BlaCoiso]

Just checked, this regressed between nightly-2022-07-09 and nightly-2022-07-10

[eddyb]

That's pretty worrying, because we don't set e.g. Debug Info Version with debuginfo disabled, and the plausible bug that #98350 introduced is that Dwarf Version would always be set when debuginfo is enabled (i.e. it's exactly as unconditional as Debug Info Version).

---

Just checked, this regressed between nightly-2022-07-09 and nightly-2022-07-10

Took a look through the PRs that landed in the latter, and aside from #98350, only #98328 could possibly affect output binaries at this level (but I fail to see how it can have any effect for windows).

The only other thing I can think of to try would be cargo-bisect-rustc (in interactive mode) - you should be able to pass --start=2022-07-09 --end=2022-07-10 to it, and then guide it based on how the resulting binary looks like.

[ehuss]

I already ran cargo-bisect-rustc, that's how I came to the conclusion in #99143 (comment) that it was #98350. Sorry if that wasn't clear.

[eddyb]

My bad - also, I was probably wasting everyone's time by not trying to borrow someone else's windows laptop.

So what's really going on is that even at -C debuginfo=0 we link debuginfo from the standard library - I bet that's why there's a .pdb at all in the first place! (which should've clued me in)

> ls $HOME/.rustup/toolchains/nightly-2022-07-09-x86_64-pc-windows-msvc/lib/rustlib/x86_64-pc-windows-msvc/lib/libstd-*.rlib
-a----         7/12/2022   9:52 PM       17610844 libstd-3aa3a0da9afb34c9.rlib

> ls $HOME/.rustup/toolchains/nightly-2022-07-10-x86_64-pc-windows-msvc/lib/rustlib/x86_64-pc-windows-msvc/lib/libstd-*.rlib
-a----         7/12/2022   9:55 PM       19936364 libstd-3aa3a0da9afb34c9.rlib

So yeah, it's #98350 via core/alloc/std being always compiled with debuginfo and statically linked into every binary (and -C prefer-dynamic does seem to avoid this, as one might expect).

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium +I-heavy