Andrew Fish [mailto:af...@apple.com] wrote:
Sent: Tuesday, November 04, 2014 11:29 AM To: edk2-devel@lists.sourceforge.net Cc: Paolo Bonzini Subject: Re: [edk2] Enable optimization for gcc x64 builds On Nov 4, 2014, at 5:48 AM, Laszlo Ersek <ler...@redhat.com <mailto:ler...@redhat.com> > wrote: diff --git a/MdePkg/Library/BasePrintLib/PrintLibInternal.c b/MdePkg/Library/BasePrintLib/PrintLibInternal.c index 8dc5ec7..fbb3726 100644 --- a/MdePkg/Library/BasePrintLib/PrintLibInternal.c +++ b/MdePkg/Library/BasePrintLib/PrintLibInternal.c @@ -680,10 +680,20 @@ BasePrintLibSPrintMarker ( if (TmpGuid == NULL) { ArgumentString = "<null guid>"; } else { + UINTN (EFIAPI * volatile PrintFunction) ( + OUT CHAR8 *StartOfBuffer, + IN UINTN BufferSize, + IN UINTN Flags, + IN CONST CHAR8 *FormatString, + ... + ); + + PrintFunction = BasePrintLibSPrint; + GuidData1 = ReadUnaligned32 (&(TmpGuid->Data1)); GuidData2 = ReadUnaligned16 (&(TmpGuid->Data2)); GuidData3 = ReadUnaligned16 (&(TmpGuid->Data3)); - BasePrintLibSPrint ( + PrintFunction ( ValueBuffer, MAXIMUM_VALUE_CHARACTERS, 0, ---------------- With this patch, GUIDs are printed okay with -Os. (Of course it's not edk2 that needs to be fixed.) 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. 2) -mabi=ms is probably little used and therefore more likely to have bugs. This might require dropping support for older gcc tool chains. 3) According to an email from you in April, ms abi might not support stack trace without debug symbols. 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. Thanks, Scott 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. 2) The var arg chain needs to be constant. I think for i386 you get lucky and the calling conventions are close enough it kind of works, but for X64 they are very different. Even if you force VA_LIST to be the Microsoft one, it is not clear to me that forces the compiler to treat every … the Microsoft way. Thanks, Andrew Fish
------------------------------------------------------------------------------
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
