(I changed the Cc to the 01.org list.) On 2015-07-23 02:46:15, David Woodhouse wrote: > On Tue, 2014-11-04 at 14:32 -0800, Jordan Justen wrote: > > On Tue, Nov 4, 2014 at 9:28 AM, Andrew Fish <[email protected]> wrote: > > > Problems with the mixed calling convention: > > > 1) All assembly routines must be marked as EFIAPI, or the C code will > > > generate the wrong calling convention. Not an issue in the MdePkg, but > > > potentially an issue in other packages. > > > > I don't see this as a problem. I think this is the rules that we have > > set up for EDK II. It just so happens that the GCC4X toolchains are > > the only ones that use EFIAPI, and thus are the only ones that allow > > us to keep our codebase clean with regards to EFIAPI. > > > > For GCC >= 4.5, I actually think we should convert *RELEASE* builds > > over to using the ms-abi all the time to generate smaller code. I > > think we should leave DEBUG builds as mixed to help clean up EFIAPI > > issues. > > Is it feasible to just kill EFIAPI completely, if GCC4X toolchains are > the only ones that use it and we can move them to -mabi=ms?
I think EFIAPI is probably about as old as EFI. Maybe Andrew would know. But, aside from its age, there is the fact that the UEFI spec has EFIAPI on all public interfaces. In EDK II, we also use it at library and assembly interface boundaries. I don't think we should try to remove EFIAPI. Now, the next question is should we just use -mabi=ms to make GCC builds less likely to fail when people misuse EFIAPI. Despite the fact that this causes me extra effort as a GCC based EDK II developer, I am still against changing this. I think this is the *only* tool we have in EDK II to keep the code base clean with regards to EFIAPI. It is unfortunate that the GCC developers solely bear the burden of debugging these issues. > Tim pointed out that vendors use it on 32-bit targets to use __fastcall > for internal functions. If that's a worthwhile optimisation it might > make sense to merge that properly — perhaps using an annotation for the > *internal* functions where it makes most sense, rather than having to > annotate the EFIAPI functions? But quite frankly, if they're not > contributing optimisations upstream in a timely fashion then we > *really* shouldn't be pandering to them. If that's the only remaining > use case then we should let it die. > > If we *can't* kill EFIAPI completely, then we need to get GCC's > __builtin_va_list to do the right thing according to the ABI of the > function it happens to be compiling at the time. This is > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818 I think EDK II and UEFI avoid using VA LIST on public interfaces... -Jordan _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
