diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2022-11-21 14:11:10 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-11-21 14:11:10 +0100 |
| commit | cc2397b2cd654833b3f02a4153819a9be3824860 (patch) | |
| tree | 318cddc1d368e560c3f0121023c574419f3589cd /compiler/rustc_codegen_llvm/src/errors.rs | |
| parent | b39e0c23bb6b285754b6b38a731846c69b4c3269 (diff) | |
| parent | 67e746cc688ec6f02a446c6e17d269ce81c1737b (diff) | |
| download | rust-cc2397b2cd654833b3f02a4153819a9be3824860.tar.gz rust-cc2397b2cd654833b3f02a4153819a9be3824860.zip | |
Rollup merge of #104511 - dpaoliello:privateglobalworkaround, r=michaelwoerister
Mark functions created for `raw-dylib` on x86 with DllImport storage class Fix for #104453 ## Issue Details On x86 Windows, LLVM uses 'L' as the prefix for any private global symbols (`PrivateGlobalPrefix`), so when the `raw-dylib` feature creates an undecorated function symbol that begins with an 'L' LLVM misinterprets that as a private global symbol that it created and so fails the compilation at a later stage since such a symbol must have a definition. ## Fix Details Mark the function we are creating for `raw-dylib` with `DllImport` storage class (this was already being done for MSVC at a later point for `callee::get_fn` but not for GNU (due to "backwards compatibility")): this will cause LLVM to prefix the name with `__imp_` and so it won't mistake it for a private global symbol.
Diffstat (limited to 'compiler/rustc_codegen_llvm/src/errors.rs')
0 files changed, 0 insertions, 0 deletions
