On 07/23/15 14:17, David Woodhouse wrote: > On Thu, 2015-07-23 at 12:31 +0200, Laszlo Ersek wrote: >>> 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), > > Right, thanks. Sorry, I'd actually worked this out before I sent my > email but forgot to remove the question. > > The problem is *solely* about choosing the right conventions for > va_list handling, according to the ABI. It's *all* about GCC PR#50818. > >> >>>> 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. :) > > Lucky you :) > >> 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. > > Right. So what are the options? > > 1. Push a patch into OpenSSL upstream that marks ERR_add_error_data() > and any other varargs functions with EFIAPI. (Ick, no. I can't > imagine them accepting that requirement.) > > 2. Maintain the same patch for ourselves in perpetuity. (Ick, we > really don't *want* to be carrying patches, especially like that > one.) > > 3. Switch to -mabi=ms across the board (can we ditch GCC 4.4?) > > 4. Fix PR#50818. (Doesn't help until we can require a fixed GCC, in > which case we might as well just go with option #3). > > 5. Add -UNO_BUILTIN_VA_FUNCS to OpenSSL build flags or otherwise > tweak OpenSslSupport.h to avoid tripping up on it. (As with option > #1 and #2, this might work for OpenSSL but I'd rather have a fix > for the *general* case of non-explicitly-EFIAPI varargs functions. > Those are currently broken on x86_64 ELF builds *anywhere* in > Tianocore, right? Like in the PrintString function in > DuetPkg/DxeIpl/Debug.c, found with a very quick grep...) > > Anything I missed? > > I'm leaning towards a combination of #3 and #5. Switch to -mabi=ms > where we can, so the whole mess can go away in time. And the minimal > tweak to fix it for OpenSSL builds, although there *are* still issues > elsewhere in the tree.
I'd go with #3 (phase out gcc-4.4, hardcode -mabi=ms). I recently experimented with setting up a minimal, local "edk2 build farm", for the gcc versions supported by edk2. Most of the details are irrelevant, but I'll share how I picked the OS releases for the builder virtual machines: - I went to koji - for each gcc version in 4.4 through 4.9, I located the *latest* fcXX distro tag that still shipped that gcc version The following mapping resulted: - gcc-4.4 -> fc13 - gcc-4.5 -> fc14 - gcc-4.6 -> fc16 - gcc-4.7 -> fc18 - gcc-4.8 -> fc20 - gcc-4.9 -> fc21 Now, according to wikipedia, Fedora 13 reached End-of-life on 2011-06-04. That's more than four years ago. Yes, RHEL-6 too provides gcc-4.4. I don't care. The RHEL-6 host kernel cannot run OVMF with pflash-based, persistent UEFI variables anyway. So losing the capability to build OVMF wouldn't be such a big problem. Jordan mentioned (IIRC) that he preferred EFIAPI to make an actual difference in DEBUG builds, in order to maintain the EFIAPI-cleanness of the tree. I believe I disagree with that; to me it seems to be a circular argument. The tree needs to be EFIAPI-clean *only* if EFIAPI actually makes a difference, and if (consequently) there's a potential to break stuff by getting EFIAPI wrong. However, if EFIAPI is a no-op, then this possibility for breakage falls away, and we shouldn't have to care about any such cleanness. As Peter said, the EFIAPI requirement is not a source level (ie. API) one, it's an ABI one. If we can ensure the ABI compatibility, with whatever means possible, we're good. A global -mabi=ms setting would suffice. ... I realize this might be a knee-jerk opinion, but it's mine :) Thanks Laszlo ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
