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
