Hi Ryan, Quoting Ryan Lahfa (2023-10-26 23:59:50) > Here's an alternative version I have been thinking of, which requires > some modifications to LLVM,
What modifications would be required to LLVM? It is probably best to push those through LLVM first before we add anything to GNU config, which takes triple stability very seriously. > + -uefi- | Yikes, this is what I had meant to write in my patch, rather than just `uefi-`. I wish config.sub's testsuite allowed "must reject" testcases. I should write a patch to add that. > uefi--coff | uefi--pe | uefi-none- | uefi-- | none-uefi-coff | none-uefi-pe | > none-uefi-) > + os= > + kernel=uefi > + obj=coff > + ;; I'm not sure these are such a great idea. I don't believe there are any other triples which are parsed with a blank os (i.e. the empty string "") and a non-empty-string kernel. The coherency of the parsing scheme sort of relies on that: # The goal of this file is to map all the various variations of a given # machine specification into a single specification in the form: # CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM # or in some cases, the newer four-part form: # CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM # It is wrong to echo any other type of specification. At minimum I think your patch needs to modify the last line of that comment as well, since it conflicts with the canonical triples it emits. But I think there will be other problems with trying to sneak an "executable format" field in here. GNU triples don't have a separate "executable format" field; it's inferred from the operating system if there is one, and only if there is no other operating system is "coff" allowed to be used as "the least operating system specification which requires coff but makes no other demands". That description doesn't really fit UEFI -- it demands a calling convention and other things too.
