`__CxxFrameHandler3` still referenced even though `panic=abort`

[ChrisDenton]

Code

I tried this code:

fn main() {}

With this section in Cargo.toml:

[profile.release]
panic = 'abort'
lto = true

And also disabled msvcrt.lib. Unfortunately rust does not have a good way to do this so I used a build script to add a libs directory that contains an empty msvcrt.lib:

use std::{env, path::Path};

fn main() {
    // Disable msvcrt.lib
    let dir = env::var_os("CARGO_MANIFEST_DIR").unwrap();
    let dir = Path::new(&dir).join("libs");
    println!("cargo:rustc-link-search=native={}", dir.display());
}

For a full example see: https://github.com/ChrisDenton/panic-abort

I expected to see this happen: When running cargo build --release, the symbol __CxxFrameHandler3 is not referenced at all. Because with panic=abort there should be no panic code.

Instead, this happened: __CxxFrameHandler3 is referenced. This causes the following linker error because I disabled msvcrt.lib:

error LNK2001: unresolved external symbol __CxxFrameHandler3

Version it worked on

It most recently worked on: 1.59

rustc +1.59 --version --verbose

rustc 1.59.0 (9d1b2106e 2022-02-23)
binary: rustc
commit-hash: 9d1b2106e23b1abd32fce1f17267604a5102f57a
commit-date: 2022-02-23
host: x86_64-pc-windows-msvc
release: 1.59.0
LLVM version: 13.0.0

Version with regression

rustc +1.60 --version --verbose:

rustc 1.60.0 (7737e0b5c 2022-04-04)
binary: rustc
commit-hash: 7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c
commit-date: 2022-04-04
host: x86_64-pc-windows-msvc
release: 1.60.0
LLVM version: 14.0.0

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[ChrisDenton]

@BatmanAoD I think this suggests that panic's unwind structs are being included even when panic=abort? Whereas before it wasn't?

[Urgau]

Because with panic=abort there should be no panic code.

I don't think this is true, the C-unwind ABI still needs it even in panic=abort, otherwise we would not be able to catch the panic and turn it into an abort.

[ChrisDenton]

Hm, then why did it only start needing it with 1.60?

[apiraino]

probably a bisection could help understanding when this started

@rustbot label e-needs-bisection t-compiler

[Urgau]

Hm, then why did it only start needing it with 1.60?

Probably because there was a fix in 1.60. There are currently some effort that are being done to fix the unsoundness around the C ABI when unwinding. Or maybe there is just something that now requires it.

[ChrisDenton]

probably a bisection could help understanding when this started

Regression was in nightly-2022-01-19. I'm still attempting to narrow it down:

found 6 bors merge commits in the specified range
  commit[0] 2022-01-17UTC: Auto merge of #90986 - camsteffen:nested-filter, r=cjgillot
  commit[1] 2022-01-17UTC: Auto merge of #93009 - matthiaskrgr:rollup-3fkxg6i, r=matthiaskrgr
  commit[2] 2022-01-18UTC: Auto merge of #93001 - flip1995:clippyup, r=Manishearth
  commit[3] 2022-01-18UTC: Auto merge of #93021 - matthiaskrgr:rollup-o7z8zoe, r=matthiaskrgr
  commit[4] 2022-01-18UTC: Auto merge of #87648 - JulianKnodt:const_eq_constrain, r=oli-obk
  commit[5] 2022-01-18UTC: Auto merge of #92731 - bjorn3:asm_support_changes, r=nagisa
ERROR: no CI builds available between ee5d8d37baaf5b5a81a98396952839c73ae41c68 and 9ad5d82f822b3cb67637f11be2e65c5662b66ec0 within last 167 days