Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Regression] GlobalValue with DLLImport Storage is dso_local! #101377

Closed
asensio-project opened this issue Sep 3, 2022 · 3 comments · Fixed by #101413
Closed

[Regression] GlobalValue with DLLImport Storage is dso_local! #101377

asensio-project opened this issue Sep 3, 2022 · 3 comments · Fixed by #101413
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.

Comments

@asensio-project
Copy link

Hello,

I was trying to compile the uefi crate, but I can't compile it with nightly-2022-09-02. The previous nightly works fine.

I get:
GlobalValue with DLLImport Storage is dso_local!
ptr @_ZN4core7unicode12unicode_data11white_space14WHITESPACE_MAP17h76c794c1a16111d0E
LLVM ERROR: Broken module found, compilation aborted!

Maybe, the pr that broke it is #100537.

@nikic nikic added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Sep 3, 2022
@nicholasbishop
Copy link
Contributor

nicholasbishop commented Sep 3, 2022

Confirmed with cargo-bisect-rustc --with-src --preserve --start 2022-09-01 -- build --target x86_64-unknown-uefi that #100537 is where it starts failing:

searched nightlies: from nightly-2022-09-01 to nightly-2022-09-03
regressed nightly: nightly-2022-09-02
searched commit range: 9243168...2e35f95
regressed commit: aa857eb

bisected with cargo-bisect-rustc v0.6.4

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --preserve --start 2022-09-01 -- build --target x86_64-unknown-uefi 
# Cargo.toml:
[dependencies]
uefi = "0.16.1"
uefi-services = "0.13.1"

# .cargo/config.toml:
[unstable]
build-std = ["core", "compiler_builtins", "alloc"]
build-std-features = ["compiler-builtins-mem"]
// src/main.rs:
#![no_main]
#![no_std]

use uefi::prelude::*;

#[export_name = "efi_main"]
pub extern "C" fn main(_h: *mut core::ffi::c_void, mut st: SystemTable<Boot>) -> usize {
    uefi_services::init(&mut st).expect("Failed to initialize utilities");

    0
}

The uefi-services crate specifically seems to trigger the failure, compiling with just uefi seems OK.

@nicholasbishop
Copy link
Contributor

Here's a slightly reduced test case:

# Cargo.toml:
[dependencies]
log = { version = "0.4.5", default-features = false }

# .cargo/config.toml:
[unstable]
build-std = ["core", "compiler_builtins", "alloc"]
build-std-features = ["compiler-builtins-mem"]
// src/main.rs:
#![no_main]
#![no_std]

use core::ffi::c_void;

#[panic_handler]
fn panic_handler(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

#[export_name = "efi_main"]
pub extern "C" fn main(_h: *mut c_void, _st: *mut c_void) -> usize {
    log::error!("hello");

    0
}

Build output:

$ cargo +nightly build --target x86_64-unknown-uefi
   Compiling compiler_builtins v0.1.79
   Compiling core v0.0.0 (/var/home/nbishop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling log v0.4.17
   Compiling rustc-std-workspace-core v1.99.0 (/var/home/nbishop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling alloc v0.0.0 (/var/home/nbishop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc)
   Compiling cfg-if v1.0.0
   Compiling bug v0.1.0 (/var/home/nbishop/src/rust-broken-link)
GlobalValue with DLLImport Storage is dso_local!
ptr @_ZN3log20MAX_LOG_LEVEL_FILTER17h159617aa6246edb9E
LLVM ERROR: Broken module found, compilation aborted!
error: could not compile `bug`

It seems the issue here is the switch from PIC to static for the reloc model in the UEFI targets. I will put up a PR to switch it back.

@dvdhrm
Copy link
Contributor

dvdhrm commented Sep 5, 2022

It feels wrong to produce executables with DLLImport annotations, knowing that UEFI loaders will never read .idata sections. While technically they could, I am not aware of any such implementations and the spec clearly states All other linkage to and from an UEFI image is done programmatically.

So I think there is some bug hiding somewhere. However, reverting to PIC to get things working is preferable to the status quo.

The linked PR looks good to me!

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Sep 10, 2022
…static-reloc, r=petrochenkov

Use RelocModel::Pic for UEFI targets

In rust-lang#100537, the relocation model for UEFI targets was changed from PIC (the default value) to
static. There was some dicussion of this change here: rust-lang#100537 (comment)

It turns out that this can cause compilation to fail as described in rust-lang#101377, so switch back to PIC.

Fixes rust-lang#101377
@bors bors closed this as completed in 54d9ba8 Sep 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants