On Thu, Jul 23, 2015 at 12:06:01AM +0100, 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?
Because the compiler doesn't do __attribute__((__ms_abi__)) thunking when it emits __builtin_va_*() handling code. Though you could look at that as a gcc bug - i.e. if the function has the attribute, emit __builtin_ms_va_copy() etc. At some point I do wonder if we wouldn't be better off making EFIABI an empty define and building with -mabi=ms . Is there a reason not to aside from some people's loathing of the less efficient ms abi that got us in to this mess to begin with? > > 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? :) > > > 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? ... So of course you had the same thought. > 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? Is there a > PR for that already? I don't know of one, but I haven't looked any harder than you have. -- Peter ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel