================
@@ -820,43 +820,6 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public
X86TargetInfo {
}
};
-// x86-64 UEFI target
-class LLVM_LIBRARY_VISIBILITY UEFIX86_64TargetInfo
- : public UEFITargetInfo<X86_64TargetInfo> {
-public:
- UEFIX86_64TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
- : UEFITargetInfo<X86_64TargetInfo>(Triple, Opts) {
- this->TheCXXABI.set(TargetCXXABI::Microsoft);
----------------
frobtech wrote:
UEFI has nothing to say about C++. It is an ABI spec that is described in terms
of C. It says nothing about what code not directly interacting with UEFI ABIs
might do.
That said, heretofore the only way to compile code directly for the UEFI ABI is
to use the Windows target. Thus, the expectations for existing source code
that targets UEFI directly via Clang is to get all the ABI and API details of
whatever language as the Windows target does them (except of course for the
actual OS-specific aspects per se). So for all "ABI choice" things, the
sensible default for UEFI target on $ARCH is what the Windows target for $ARCH
does. This goes for what type long is, what C++ ABI to use, alignment quirks,
etc. It also goes for language API details/extensions that are not directly
related to Windows per se, such as the various pragmas for PECOFF-specific
features or Windows spellings of generic extensions (e.g. `-fms-extensions`
stuff).
Once we have the UEFI targets on their feet, we'll want to look into offering
flexibility to make non-default choices (i.e. choices different from Windows)
for various ABI and API things. But we can get to that later.
https://github.com/llvm/llvm-project/pull/120632
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
