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.
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?
I also noticed that the binary size of ms ABI is smaller than the binary size
of the same source code compiled with SYSV ABI.
Thanks,
Ari
From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, March 12, 2014 4:11 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFIAPI Calling Convention
On Mar 11, 2014, at 6:17 PM, Ben Schroeder
<ben...@mellanox.com<mailto:ben...@mellanox.com>> wrote:
Hi,
Regarding EFIAPI calling convention, the UEFI 2.3.1 specification writes:
"All public interfaces of a UEFI module must follow the UEFI calling
convention. Public interfaces include the image entry point, UEFI event
handlers, and protocol member functions. The type EFIAPI is used to indicate
conformance to the calling conventions defined in this section. Non public
interfaces, such as private functions and static library calls, are not
required to follow the UEFI calling conventions and may be optimized by the
compiler"
Specifically I am interested in UEFI event handlers.
I have a function that registered with CreateEvent as a timer, and then
registered with SetTimer to be polled periodically.
So I understand this function (call it foo()) must have EFIAPI calling
convention (because it will be called periodically by the uefi system)
That is correct.
Do functions that are called by foo() also need to be in EFIAPI convention?
No
Specifically, every function that foo() calls, and all the functions those
functions call, and so forth, all need to be EFIAPI convention?
No.
Think of it this way EFI Firmware is compiled with compiler A, and your Option
ROM is compiled with compiler B. The public interfaces are places where the
code is not linked together, could be generated by different compilers, and you
are changing execution between different binaries that are not linked together.
At this point you have to follow the calling convention. So EFIAPI exists to
help enforce the need to have correct calling convention regardless of the
compiler flags, or compiler you are using. In reality most of the compilers we
use conform to the EFIAPI (It is a subset of Windows ABI) and the compiler is
smart enough to know that some other chunk of code it does not control can call
the API, so leave it in the standard state. There are some flavors of GCC where
EFIAPI actually maps to an attribute that informs the compiler to use a
different calling convention. So the BIG issue here is miss use of EFIAPI does
not show up in a lot of the compilers.
What your compiler does in code that it calls is up to the compiler. The
compiler can inline functions, use tail calls, or even makeup a calling
convention (pass args in registers on IA32). As compilers get smarter,
optimizations get crazier.
Actually the debugger I use daily (lldb) does not have a concept of EFIAPI for
X64 (x86_64), but it works just fine. The reason is due to to compiler
optimization it can never assume what the calling conventions are, so the debug
information gives you the extra ABI support for free.
Thanks,
Andrew Fish
Thanks,
Ben.
------------------------------------------------------------------------------
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<mailto: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
