On 23/07/2015 11:46, 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 <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.
"ix86/gcc-4_4-branch" sounds like an internal branch for use by Intel engineers. Features are not backported to stable branches. >> 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 Am I CCed because you'd like me to fix it? :) I can take a look. Paolo ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
