On Tue, 2014-11-04 at 14:32 -0800, Jordan Justen wrote: > On Tue, Nov 4, 2014 at 9:28 AM, Andrew Fish <af...@apple.com> wrote: > > So my 1st question is why do you need to mix calling conventions, > > and depend > > on EFIAPI for interoperability. Why not just change the ABI on all > > functions? > > GCC 4.4 doesn't support the command line option to change everything > over. So, EFIAPI was the only option then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39472#c8 suggests that the support was backported to GCC 4.4 too. > > 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? 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 -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
