Repository: rust
Issue: `raw-dylib` usage in std broke thumbv7a-*-windows-msvc targets
Labels: I-crash,A-LLVM,A-cross,T-compiler,O-windows-msvc,C-bug,-Zbuild-std

Starting from `nightly-2024-02-26` rust version `1.78.0-nightly (0ecbd0605 2024-02-25)`, `std` for `thumbv7a-uwp-windows-msvc` no longer builds:

```bash
cargo +nightly-2024-02-26 build -Z build-std=std,panic_abort --target thumbv7a-uwp-windows-msvc --release
```

<details>
<summary>Output:</summary>

```
...
error: could not compile `std` (lib)                                                                                                                           

Caused by:
  process didn't exit successfully: `C:\Users\bdbai\.rustup\toolchains\nightly-2024-02-26-x86_64-pc-windows-msvc\bin\rustc.exe --crate-name std --edition=2021 C:\Users\bdbai\.rustup\toolchains\nightly-2024-02-26-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=158 --crate-type rlib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg "feature=\"addr2line\"" --cfg "feature=\"backtrace\"" --cfg "feature=\"gimli-symbolize\"" --cfg "feature=\"miniz_oxide\"" --cfg "feature=\"object\"" --cfg "feature=\"panic_unwind\"" --cfg "feature=\"std_detect_dlsym_getauxval\"" --cfg "feature=\"std_detect_file_io\"" -C metadata=e432070f6e8a70e3 -C extra-filename=-e432070f6e8a70e3 --out-dir C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps --target thumbv7a-uwp-windows-msvc -Z force-unstable-if-unmarked -L dependency=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps -L dependency=C:\project_dir\target\release\deps --extern priv:addr2line=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\libaddr2line-08740835d495a638.rmeta --extern alloc=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\liballoc-ffcd7e68b1b4d768.rmeta --extern priv:cfg_if=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\libcfg_if-ed9aa18cde72cb83.rmeta --extern priv:compiler_builtins=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\libcompiler_builtins-4dc2d4fb24785f49.rmeta --extern core=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\libcore-e9d96bbb4564a7c8.rmeta --extern priv:hashbrown=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\libhashbrown-bbafedfdf9ba97f2.rmeta --extern libc=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\liblibc-b57e343fcebc03aa.rmeta --extern priv:miniz_oxide=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\libminiz_oxide-58abf01af28732ef.rmeta --extern priv:object=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\libobject-d7dbd142c5e57f98.rmeta --extern priv:panic_abort=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\libpanic_abort-d509d9c2350c464a.rmeta --extern priv:panic_unwind=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\libpanic_unwind-ba05a49921f1f9c0.rmeta --extern priv:rustc_demangle=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\librustc_demangle-d8165352be6fe153.rmeta --extern priv:std_detect=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\libstd_detect-937e46cacab5d26e.rmeta --extern priv:unwind=C:\project_dir\target\thumbv7a-uwp-windows-msvc\release\deps\libunwind-bd6619bcb4fe0878.rmeta -Z unstable-options --cap-lints allow --cfg backtrace_in_libstd` (exit code: 0xc000001d, STATUS_ILLEGAL_INSTRUCTION)
warning: build failed, waiting for other jobs to finish...
...

```

</details>

This looks very similar to the error reported in #120921 , which indicates somewhere in std is using `raw-dylib` already and triggers the same issue within llvm. Looks like #121337 is the first PR that introduces `raw-dylib` and so far there are a handful of other places (like https://github.com/rust-lang/rust/commit/f68529f2cf364469575b61fdeb3b901eb3d86328) using it as well. Given llvm is having issues for this particular platform, can we consider excluding `thumbv7a` from using `raw-dylib` in `std`, or at least there would be a way to workaround this?

Ping @ChrisDenton @bjorn3