Separate x64#105
Conversation
This adds a few things to .gitignore: - vim and emacs temporary files - generated source files - our target object directories Signed-off-by: Peter Jones <pjones@redhat.com>
This adds two new make variables, OPTIMIZATION_CFLAGS and DEBUG_CFLAGS, and moves the relevant compiler flags from EFI_CFLAGS into those variables. This makes it easier to align those options with applications using consuming this library. Signed-off-by: Peter Jones <pjones@redhat.com>
This adds a build variable, GNU_EFI_EXPORT_MS_ABI, that allows an application consuming gnu-efi to build the entire tree with -mabi=ms. This has numerous advantages, not least traceback handlers that expect that ABI will seamlessly walk the call stack from a faulting function all the way up into the firmware correctly. As an implementation detail, this changes the ABI of _entry() to effectively be EFIAPI, and as such on x86_64 that means _start has to call _entry() with those conventions. If it weren't for this detail we wouldn't actually need the GNU_EFI_EXPORT_MS_ABI variable, we could just pass -mabi=ms in to EFI_CFLAGS. Signed-off-by: Peter Jones <pjones@redhat.com>
This breaks out x86_64 and x64 as two separate arches, and treats x64 as the microsoft-defined 64-bit ABI and x86_64 as the system-v defined version. Signed-off-by: Peter Jones <pjones@redhat.com>
This adds the new x64 ABI targets to CI, and by doing so changes the old one to be named x86_64 where applicable. Signed-off-by: Peter Jones <pjones@redhat.com>
|
Shoot, I was hoping there would be some time between proposal and merge, because, my view is that we should have waited for a major revision to switch to making My understanding is that EDK2 does use But, in case this is a potentially breaking change, we want to do that on a major release, though I guess we can start with introducing the whole thing as optional for now, and then switch to making it the default later, when we do a major release. And I really don't think that we want to continue to carry two implementations of x86_64 for builds/testing (which does not mean that we won't try to fix issues reported to us) because if we start to test for every build flag/option people can add to gnu-efi, we're never going to see the end of it. We should build/test for the default flags (so x64 should be whatever defaults we go with), and only look into building/testing nondefaults if people report issues with that. |
|
I'll agree that we should not carry two versions of x86_64. |
|
I was also going to review this and comment regards the dual x64 issue so I wholly agree with what @pbatard is saying. We should also consider ARM64 I think (I am writing this without reviewing the specification) because it also has ms_abi specific changes (at least for va_args) in the pipeline so if we do for one we must do for all applicable architectures. I would also agree that such a change is ABI breaking so is gnu-efi v5 |
4 participants
This PR separates the two possible ABIs on 64-bit x86 platforms into distinct target arches. In doing so, it uses the x64 name for binaries using the Microsoft / EFI calling convention, and the x86_64 name for using the "System V" / ELF calling conventions.
On linux CI targets, we use that nomenclature as above. On Windows it's a little more (or rather less) complicated - since vs2026 has always natively targeted their ABI.