On Mar 11, 2014, at 6:17 PM, Ben Schroeder <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
> 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
