I’m not sure why the __attribute__ is used vs. the entire calling convention it did not do the GCC port. I maintain the clang toolchain, and the early work on edk2 was done with VC++.
The EFIABI is also used on library APIs. The reason is if the library function is implemented in assembler the calling convention matters. I can see 2 reasons to use the EFIAPI attribute vs. a global flag: 1) Allows the use of generic SYSV ABI libraries. Maybe not a big deal if you a writing and EFI ROM, but could be a big deal if you are writing an OS loader. Maybe you need a decompression, or security lib that does not exist in EFIABI. It the library has any assembler you can’t just cross compile. 2) Not sure about this: For X64 with ms_abi you can not get a stack trace without the debug symbols information (). It is possible to get a stack trace SYSV ABI. Thanks, Andrew Fish On 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
