> 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. >
Rusian, 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: https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template <https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template> 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. Thanks, Andrew Fish > 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 >> code. >> > > Ruslan, > > 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. > > Thanks, > > 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: >> https://bugzilla.tianocore.org/show_bug.cgi?id=870 >> It is very straight-forward. Can someone review it, and, hopefully, commit >> the change? >> >> >> Ruslan, >> 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 >> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template >> you will see that you can use Xcode to build EFIAPI if you pass -target >> x86_64-pc-win32-macho. >> 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... >> Thanks, >> Andrew Fish >> >> - Ruslan >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >> >> >> >> >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > > > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
