Add support for UEFI targets

[joschock]

Add support for compiling for UEFI targets such as x86_64-unknown-uefi and aarch64-unknown-uefi.

These targets do not support the default feature set given the bare metal nature of the UEFI environment, and this exposed some minor warnings when compiling without the default features, so this PR also addresses those.

[joschock]

@Amanieu do you have any concerns with this approach?

[Amanieu]

What kind of stack unwinding do the UEFI targets use? This is relevant if we want to properly support backtraces, even if the code is being built with panic=abort.

[joschock]

What kind of stack unwinding do the UEFI targets use? This is relevant if we want to properly support backtraces, even if the code is being built with panic=abort.

UEFI spec requires images to be PE/COFF - so PDBs and PE-style .pdata/.xdata are what most debuggers expect and what our project supports (https://github.com/OpenDevicePartnership/patina/tree/main/core/patina_stacktrace). But I struggled to figure out how to plumb in the proper directives for generating appropriate debug data. The present aarch64 targets build targeting DWARF/CFI, and the present PE-style target (for windows) has a lot of extra logic around windows stack requirements and TEB that don't apply. In the end, I decided to submit this as a baseline PR; but I'm open to help/guidance on how best to properly accomplish that aspect.

[Amanieu]

I had a look at what would be necessary to support SEH unwinding under UEFI. On x86_64, I think it should just be a matter of porting the .seh_ annotations from the Windows code to the non-Windows one. This should only be done for UEFI targets, but you can use a macro similar to dwarf! in x86.rs to do this (e.g. seh!()).

You will probably need to adjust the offsets a bit since the TEB fields don't need to be saved on the stack. You'll also need to add the fake RIP value by copying the first 2 instructions of switch_and_link from x86_64_windows.rs.

Would you be able to test stack trace generation from within a coroutine on UEFI?

[joschock]

Would you be able to test stack trace generation from within a coroutine on UEFI?

Yes, we have a debugger that supports a GDB remote, which we can connect to via LLDB or WinDbg; we can also generate a direct stack trace (i.e. as a result of a panic!()) using the built in stack trace routine (linked above).

I'm happy to take a shot at the SEH unwinding support - would you like that folded into this PR or as a separate subsequent PR?

[joschock]

Also - any thoughts on unwind support for AARCH64 UEFI targets? Your X86 comments make sense; I follow - but aarch64 is a bit more mystifying to me, since I'm not sure how to encode the cfi equivalents using seh

[Amanieu]

Sure, let's leave SEH to a separate PR. This is good enough for basic functionality for now.

[Amanieu]

Regarding AArch64 SEH unwinding, that's more complicated since AArch64 SEH uses completely different unwinding opcodes. Let's ignore it for now.