Investigate why the UEFI targets produce executables with `DLLImport` annotations

[nicholasbishop]

This is a followup to #101377.

Originally posted by @dvdhrm in #101377 (comment):

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.

[dvdhrm]

I tracked this down. The error we get is in the LLVM IR verification. Globals (code, data, ...) are called GlobalValue in the IR and can have a set of attributes. One of those is called dso_local (the linker / lto-compiler can rely on the symbol to be local and not interposable), another is called dllimport which just tells the compiler to use indirect-calls as is common for dll imports.

The llvm-codegen always marks rust symbols from crates other than the current compilation as DllImport (search for DllImport in compiler/rustc_codegen_llvm/src/consts.rs). This allows dynamic linking between rust crates, while relying on the linker to correctly fix things up when linking statically.

At the same time, when dropping PIC and using the static relocation model, all symbols in a compilation are marked as dso_local, because the assumption is that nothing is ever linked dynamically. LLVM now correctly complains that the combination makes no sense.

I think the underlying issue is that LLVM does not silently ignore DllImport, while rustc assumes that it is safe to set DllImport even when linking statically. One possible solution would be to never set DllImport if the target uses a static relocation model. This should fix the issue, but... I don't have enough insight into the LLVM codegen right now to evaluate whether this is the correct approach. I will try to file a PR and then we can continue discussion there.

[dvdhrm]

This is now fixed with a0771bd (issue #104679). @nicholasbishop you want to close this?

[nicholasbishop]

Closing, thanks for fixing that.