Build as a 'bin' crate, linking with rust-lld

[ids1024]

This eliminated the two awkward ld steps from the Makefile, and seems to produce a smaller .efi. It seems to work, based on quick testing in qemu.

Using 'uefi' for target because apparently Rust cares: rust-lang/rust#71881

Some changes to the target specification here are from rustc -Z unstable-options --print target-spec-json --target x86_64-unknown-uefi. We probably want more of the settings from there, but most likely still need our own custom target to change some things.

[crawfxrd]

Nice. I couldn't get this working last night when I tried to copy the x86_64-unknown-uefi spec.

the two awkward ld steps

These aren't awkward. They're downright black magic. I'd be glad to see them gone.

We probably want more of the settings from there

stack-probes will be needed for firmware-smmstore.

But we should try to align to the target as close as possible.

The target name should probably be updated too to better match the builtin target, for anything special core or compiler_builtins do. Something like x86_64-unknown-uefi-drv?

[ids1024]

They're downright black magic.

Linkers are invariably black magic. But hopefully if we have Rust doing the linking for us, we only have to worry about a smaller subset of the arcana...

But we should try to align to the target as close as possible.

The standard x86_64-unknown-uefi target seems to work as well, after changing pre-link-args. The changes in the PR should be the minimum required changes to the current target file.

Too bad Rust target specifications don't seem to support an "inherits-from" option or anything like that...

x86_64-unknown-uefi uses "panic-strategy": "abort", while it seems we're currently using unwinding panics. Are those unwinding panics actually behaving sensibly?

For ABI details, I suppose we want the same thing as ``x86_64-unknown-uefi`, assuming it's correct. I'm sure issues there can lead to some great bugs...

The target name should probably be updated too to better match the builtin target, for anything special core or compiler_builtins do. Something like x86_64-unknown-uefi-drv?

Sounds good.

[crawfxrd]

Are those unwinding panics actually behaving sensibly?

We're calling to/from C code (edk2), so I don't think we should be unwinding in the first place. abort seems correct.

Most of the other options that we specify that aren't in x86_64-unknown-uefi seem to be the default, so could be removed.

• x86_64_unknown_uefi.rs
• uefi_msvc_base.rs
• msvc_base.rs
• mod.rs

[ids1024]

We're calling to/from C code (edk2), so I don't think we should be unwinding in the first place. abort seems correct.

Apparently Rust has a working group for unwinding across FFI boundaries: https://github.com/rust-lang/project-ffi-unwind

If we're not even testing it, we can probably expect unwinding isn't working quite how it should. (It's also worth noting that abort generates smaller binaries.)

So using x86_64-unknown-uefi, but modified just to change the link flags, seems reasonable. Actually, if desired we could do that without a custom target spec by passing Rustc arguments, but it may be better to use the target spec (so we can easily change other things if needed, etc.).

[ids1024]

I've pushed an update using a x86_64-unknown-uefi-drv target, that is the same as the standard target except changes to the linker arguments.