On 07/23/15 01:06, David Woodhouse wrote: > On Thu, 2015-07-23 at 00:44 +0200, Laszlo Ersek wrote: >> I "guess" it should work at the moment (and -UNO_BUILTIN_VA_FUNCS would >> be easy enough to add under [BuildOptions] in >> "CryptoPkg/Library/OpensslLib/OpensslLib.inf"). >> >> But, as soon as a "genuinely" EFIAPI function with a variable argument >> list appeared in "OpensslLib.inf", things would break again. > > I'm slightly confused. Why does it *only* matter for varargs functions? > I thought that on some platforms, the difference between the ELF ABI > and the MS ABI extended to putting arguments in *completely* different > registers? Why doesn't that bite us?
It does not bite us because the calling convention is part of the function's prototype (the declaration in the header file), and the compiler: - adheres to the calling convention in callers -- arguments are marshalled accordingly, - enforces that calling convention when it sees the definition of the function -- if the definition doesn't match the declaration, the build breaks with an error. If the definition matches the declaration, then the arguments are de-marshalled accoringly. Difference with varargs functions: - the compiler *does not* enforce in the function definition that the VA_* macros actually match the calling convention posited in the function declaration. Arguments are de-marshalled manually, and if we mess up, the compiler doesn't catch it, we just crash. >> Any particular reason for disliking these hunks of >> "EDKII_openssl-1.0.2d.patch" (over the other hunks)? > > Oh, I dislike lots of other bits of that too. I'm just working through > them all separately. Are you on the openssl-dev mailing list? :) Nope. :) > >> So, this issue is not fixable globally under gcc. With gcc (compiling >> for x86_64), EFIAPI and non-EFIAPI differ from each other,.. > > Well, why don't we just add -mabi=ms to the compiler flags? Then EFIAPI > in the source code could be a no-op, right? Yes, I think EFIAPI would be a no-op then. I don't know why we don't set -mabi=ms globally. Hm, wait, I do know. Because gcc-4.4 doesn't support it. See the docs: https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/i386-and-x86_002d64-Options.html The section "Intel 386 and AMD x86-64 Options" does not list "-mabi=". Apparently, the "-mabi=(ms|sysv)" option was introduced in gcc-4.5. ... Hm, that might be a glitch in the gcc-4.4 documentation. I just checked my Fedora 13 VM (with gcc-4.4), and it does know about -mabi=ms. So, I don't know. > Alternatively, why in $DEITY's name doesn't GCC give us a set of > builtin functions which actually DTRT according to whether *this* > particular function is being built with the MS ABI or not? Yes, exactly, why does it not? I agree with your sentiment 100%. > Is there a > PR for that already? I don't know. I can only refer you (again) to: <https://bugzilla.redhat.com/show_bug.cgi?id=871889>. Jakub and Kai said (in 2012) that it was a user error to expect the same builtins (or macros) to DTRT regardless of the calling convention. They said the programmer had to choose the right builtins manually. And, if I check the "stdarg.h" and "cross-stdarg.h" files on my RHEL-7.1 system, under "/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include", I still see: - "stdarg.h" is bound to the SYSV ABI - "cross-stdarg.h" is also bound to the SYSV ABI, for !__x86_64__ - "cross-stdarg.h" allows the programmer to manually choose between SYSV and MS ABI compatible builtins for __x86_64__ So, as far as RHEL-7.1 can be considered "recent", I'd say those bugzilla comments are the state of the art even today. In any case, if there was such a gcc PR, we'd still have to stick with the compatibility cruft in edk2, for old gcc versions' sake. Thanks Laszlo ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
