> On Nov 4, 2014, at 2:32 PM, Jordan Justen <[email protected]> wrote: > > On Tue, Nov 4, 2014 at 9:28 AM, Andrew Fish <[email protected]> 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. > >> 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. >
I agree it is good in keeping the edk2 code clean. I was more concerned about code from 3rd parties. So sorry this was more about a warning when you are porting code on what to look out for. I’m really only concerned about how the VA_LIST stuff is going to work? Does it need to shift for native vs. EFIAPI? If so how you pass the VA_LIST around if the code is not all the same ABI? > 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. > You guys should figure out if you can have a ms-abi but add the frame pointers. The compiler is open source …. Thanks, Andrew Fish > -Jordan ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
