> On Feb 9, 2018, at 12:13 AM, Ruslan Nikolaev <nruslan_de...@yahoo.com> wrote:
> Sorry, I did not answer this question last time. It is basically may not be
> very easy to change if you already have some assembly code which makes use of
> a specific calling convention. Plus there may be benefits of using
> register-based calls elsewhere.
> I thought, since EFIAPI aims to define a specific calling convention
> regardless of compilation flags, why not specify regparm(0) there as well.
The primary goal of EFIAPI is to make sure it produces the correct code with
the set of compilers that are supported by the edk2 project:
Thus it has the values that work correctly with the supported toolchains. It is
very hard to support some conceptual toolchain if a version of that toolchain
is not checked in as there is no way to test it.
> On Friday, February 9, 2018 2:17 AM, Andrew Fish <af...@apple.com> wrote:
>> On Feb 8, 2018, at 11:12 PM, Ruslan Nikolaev <nruslan_de...@yahoo.com> wrote:
>> Well, what I was implying is that if MdePkg (Ia32) headers are included in
>> some UEFI program which itself is compiled with some custom register-based
>> calling convention, current EFIAPI definition is insufficient.
>> Current definition with cdecl attribute merely forces caller stack clean-up
>> in gcc/clang for Ia32
>> So, if I build with '-mrtd' option (a callee cleans up the stack) current
>> EFIAPI definition will take care of it. However, if in addition to that I
>> specify -mregparm=1,2,3 to pass some parameters in registers, cdecl will not
>> take care of it.
>> EFIAPI for Ia32 wants all parameters in the stack. Therefore, it should be
>> reasonable to specify regparm(0) as part of EFIAPI definition as well, so
>> that regardless of mregparm parameter the compiler will generate correct
> Thanks for the info. I guess I still have the question of if you are making
> firmware why not solve this problem with compiler flags in the 1st place.
> Andrew Fish
>> On Friday, February 9, 2018 1:59 AM, Andrew Fish <af...@apple.com> wrote:
>> On Feb 8, 2018, at 5:32 PM, Ruslan Nikolaev <nruslan_de...@yahoo.com> wrote:
>> I submitted a bug report and a patch:
>> It is very straight-forward. Can someone review it, and, hopefully, commit
>> the change?
>> Was there an example of how to code this? Sorry if I missed it, I'm getting
>> a lot of email these days.
>> Also what is you usage model? Clang is very cross compiler friendly and you
>> can specify a triple to support the ABI you need. To get EFI supported on
>> macOS tools we ended up open sourcing a triple to support the EFIAPI. If you
>> look in
>> you will see that you can use Xcode to build EFIAPI if you pass -target
>> I guess I'm asking the question if you really need to support multiple ABIs
>> with clang? The best way to solve this in clang is to make it support
>> EFIAPI. If you don't need multiple ABIs take a look at what we did with
>> -target x86_64-pc-win32-macho, which tells clang to build EFIABI, but output
>> a mach-O executable (we need the mach-O for our debugger). Basically with
>> clang you could upstream what you need into the compiler you are using for
>> other things...
>> Andrew Fish
>> - Ruslan
>> edk2-devel mailing list
>> edk2-devel mailing list
> edk2-devel mailing list
edk2-devel mailing list