Andrew Fish [mailto:af...@apple.com] wrote:
Sent: Tuesday, November 04, 2014 03:40 PM To: edk2-devel@lists.sourceforge.net Cc: Paolo Bonzini Subject: Re: [edk2] Enable optimization for gcc x64 builds On Nov 4, 2014, at 12:15 PM, Scott Duplichan <sc...@notabs.org <mailto:sc...@notabs.org> > wrote: But pedantically you need change the definition of BasePrintLibSPrint() to include EFIAPI. If you look at BasePrintLibSPrintMarker() (and some of the other routines) you will notice a BASE_LIST and a VA_LIST. We had an API that exposed a VA_LIST (well code that was casting to VA_LIST) in the report status code stack and it forced use to use our own made up BASE_LIST concept to get it to work. I think you are going to hit similar issues mixing calling conventions. 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? If I understand your question "Why not just change the ABI on all functions", you mean use Microsoft ABI throughout the code even when compiled with gcc? The gcc option -mabi=ms makes this easy, and it reduces code size too (8% in one test). Part of that code size reduction is because it removes the requirement to save xmm6-xmm15 when calling msabi code. Gcc doesn't optimize the save/restore of xmm6-xmm15, it just does them all. The problems with ms abi I can think of are: 1) Linux developers accustomed to stepping through the sysv calling convention would have to adapt to the ms calling convention. Well all the public interfaces (EFI service, protocol member functions, etc.) are EFIAPI, so there will be a mix. 2) -mabi=ms is probably little used and therefore more likely to have bugs. This might require dropping support for older gcc tool chains. Looks like mixing has bugs too. It looks like this issue is caused by a mismatch in the vararg definitions between the two worlds. You can’t really mix styles in a given call stack. It almost seems like you want to force one var arg scheme every place possible. 3) According to an email from you in April, ms abi might not support stack trace without debug symbols. This is not the ABI it is VC++ code generation. There is nothing in the ABI about how to unwind a stack frame, it is about how to call code in C. In my clang examples, in this thread, we have an EFIAPI compatible calling convention with stack unwind. -target x86_64-pc-win32-macho means build an X64 image using EFIAPI, do the standard frame pointer, and we kick out a Mach-O executable for the debugger. We convert the Mach-O to PE/COFF for EFI compatibility. So on clang it as EFIABI, but with stack unwind. We can always unwind a frame without symbols, until we hit code compiled with VC++. Even if ms abi is never made the default for gcc code, adding an environment variable such as EXTRA_CC_FLAGS would allow its use in custom builds by those who need the code size reduction it brings. What about switching EDK2 to sysv abi? I assume that would require dropping support for Microsoft compilers. The EFI calling convention is in the spec, so all things EFI would break. Option ROMs on cards, installed Operating system, etc…. The edk2 is an open source project that implements industry standard, not just a chunk of code. Thanks, Andrew Fish These are all good answers. I can't come up with a strong argument for the mixed sysv/ms ABI. Maybe the next step is to test -mabi=ms using several gcc versions (I think -mabi=ms was introduced with gcc 4.5). If that works, I could submit a patch and see what happens.. Thanks, Scott Thanks, Scott
------------------------------------------------------------------------------
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
