Hi Adam,
Thank you for sending this patch for my usage.
Here's an alternative version I have been thinking of, which requires
some modifications to LLVM, but maybe, those are worthwhile on the long
term to tame the zoo of UEFI triples.
>From bb030174d273b525a66c5470a9e78a0cb9c00ad8 Mon Sep 17 00:00:00 2001
From: Ryan Lahfa <r...@lahfa.xyz>
Date: Wed, 25 Oct 2023 21:39:55 +0200
Subject: [PATCH 2/3] config.sub: add basic UEFI detection
Usually, UEFI is considered to be a Windows MSVC target without libc
and some extra things related to its baremetal-ish characteristics.
Nevertheless, it provides certain API facilities and is supported by
various programming languages, e.g. Rust and Zig.
To the best of my knowledge and at the time of writing, it is not possible
to compile UEFI programs without using LLVM.
GNU-EFI is a project that enable any ELF-emitting compiler to emit UEFI programs
by relying on the MinGW ecosystem. It should be considered to be a system
on its own as it does not have the same ABI as the "Windows MSVC"-ish target
that people have been using with LLVM via
`$qemuArchitecture-unknown-windows-msvc`,
an unfortunate and frustrating sharing of platform strings in my humble opinion,
because it made the situation in nixpkgs less than pleasant to
distinguish "I am compiling for Windows" and "I am compiling for UEFI"
in our code.
Also, linkage via such strings will induce a use of `lld-link` which relies on
Windows-style command line driving, e.g. `/`-style parameters instead of
`-`-style parameters.
Therefore, it should not be confused with a potential GNU variant of that
string,
which would induce, I assume, a classical command line driving. Such a
GNU variant is out of scope for this patch as it focuses on existing
compilation capabilities.
A choice has been made to support PE and COFF as object file format,
technically, PE is not an object file format, it is executable file format,
which contains itself a COFF object file format as part of its description.
A choice has been made to support os = UEFI and kernel = UEFI and it is
canonicalized into kernel = UEFI and os = <empty>.
The reason for this is that UEFI is definitely not a full blown
operating system that can be used for normal operations, it offers a
simple filesystem API, multi-threading, interruptions, networking
operations, but those are the features of a basic kernel. Therefore, we
reflect that choice in the canonicalized string.
Though, we are lenient and support people using os = UEFI and correct
it.
Note that we test the Apple vendor because technically Apple UEFI do
exist out there, while, I believe it should have no effect on the actual
results, it is tested here, just in case.
---
config.sub | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/config.sub b/config.sub
index defe52c..a4a71d7 100755
--- a/config.sub
+++ b/config.sub
@@ -1774,7 +1774,7 @@ case $os in
;;
none)
;;
- kernel* | msvc* )
+ kernel* | msvc* | uefi* )
# Restricted further below
;;
'')
@@ -1855,6 +1855,18 @@ case $kernel-$os-$obj in
;;
*-eabi*- | *-gnueabi*-)
;;
+ -uefi- | uefi--coff | uefi--pe | uefi-none- | uefi-- | none-uefi-coff |
none-uefi-pe | none-uefi-)
+ os=
+ kernel=uefi
+ obj=coff
+ ;;
+ *uefi*)
+ # UEFI can only be paired with a COFF (object file format) / PE
(executable file format).
+ # Operating system does not mean a lot in this context, UEFI is a
kernel/OS for any program running under
+ # this environment, kernel is closer to truth than operating system, in
this instance.
+ echo "Invalid configuration '$1': UEFI environment not known to work with
OS '$os' or object file format '$obj'." 1>&2
+ exit 1
+ ;;
none--*)
# None (no kernel, i.e. freestanding / bare metal),
# can be paired with an machine code file format
--
2.42.0
Kind regards,
P.S. — I have been unable to find a way to read the Reply-To to attach
correctly the answer, I hope I didn't break the mailing list etiquette.
--
Ryan Lahfa
