I tested OVMF's size when adding -mabi=ms. Perhaps we should consider adding it to the flags only for RELEASE builds. This would still allow us to find EFIAPI bugs with DEBUG builds.
X64 GCC48 compared to GCC48 + -mabi=ms DEBUG SECFV: 43480 -> 42552 (2.1% savings) FVMAIN_COMPACT: 976960 -> 960760 (1.7% savings) RELEASE SECFV: 22072 -> 21592 (2.2% savings) FVMAIN_COMPACT: 750096 -> 734408 (2.1% savings) (SECFV is uncompressed code. FVMAIN_COMPACT is compressed.) -Jordan On Fri, Mar 14, 2014 at 9:45 AM, Jordan Justen <jljus...@gmail.com> wrote: > One other advantage is that this is the only way we can identify bugs > in EFIAPI usage. > > Unfortunately, users of the GCC4X toolchains have to carry the burden > of debugging these issues. > > Best case the compiler will generate a warning to point out the issue. > Worst case, someone uses an explicit type cast to silence the error, > and then you are in for some difficult debug. > > -Jordan > > On Fri, Mar 14, 2014 at 8:42 AM, Laszlo Ersek <ler...@redhat.com> wrote: >> (apologies for butting in, I can't resist) >> >> On 03/14/14 16:13, Ari Zigler wrote: >>> Hi Andrew, >>> >>> >>> >>> Thanks for the clarification. >>> >>> >>> >>> We're using GCC 4.6 and I saw in the tools_defs.txt that our EFIAPI >>> definition is being mapped to GCC's function attribute >>> __attribute__(ms_abi) which tells the compiler to enforce ms ABI to the >>> function defined with it. >>> >>> I also tracked down a GCC flag (-mabi=ms) which enforces ms ABI globally >>> (to all of the functions in the source code). >>> >>> By inspecting the assembly code being generated with that flag and >>> comparing it to the assembly code being generated with the EFIAPI in >>> conjunction with SYSV ABI (GCC's default ABI) I noticed that they both >>> produce the same calling convention. >> >> I'd assume that happens because they mean the same. From the gcc-4.8.2 info: >> >> '-mabi=NAME' >> Generate code for the specified calling convention. >> Permissible values are 'sysv' for the ABI used on GNU/Linux and >> other systems, and 'ms' for the Microsoft ABI. The default is >> to use the Microsoft ABI when targeting Microsoft Windows and >> the SysV ABI on all other systems. You can control this >> behavior for a specific function by using the function >> attribute 'ms_abi'/'sysv_abi'. *Note Function Attributes::. >> >> 'ms_abi/sysv_abi' >> >> On 32-bit and 64-bit (i?86|x86_64)-*-* targets, you can use an >> ABI attribute to indicate which calling convention should be >> used for a function. The 'ms_abi' attribute tells the compiler >> to use the Microsoft ABI, while the 'sysv_abi' attribute tells >> the compiler to use the ABI used on GNU/Linux and other >> systems. The default is to use the Microsoft ABI when >> targeting Windows. On all other systems, the default is the >> x86/AMD ABI. >> >> Note, the 'ms_abi' attribute for Microsoft Windows 64-bit >> targets currently requires the '-maccumulate-outgoing-args' >> option. >> >>> Would you recommend using GCC with -mabi=ms flag by default when >>> compiling code for UEFI rather than count on the developer to add EFIAPI >>> to public functions? >> >> In edk2, use of EFIAPI is required on the affected types of functions. >> >> If you build outside of edk2, I would still recommend the case-by-case >> attribute (using a macro name like EFIAPI or anything else). You might >> want to link your driver or application (statically) against a >> system-provided library. Suppose this library takes some kind of >> callback function when you initialize it; you'd pass it a pointer to a >> function that you define. The library would probably not expect the >> ms_abi calling convention (which your function would be compiled for if >> you set -mabi=ms globally for the build). >> >> I think it's best to be explicit about EFIAPI. Supposing your developer >> works on Linux, and actually tests at least once each new function he >> adds, a wrong calling convention should be very quickly noticed. >> >> For example, gnu-efi seems to use EFIAPI explicitly. >> >> Just my two cents; Andrew will probably have more insight. >> >> Thanks >> Laszlo >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
