On 07/23/15 15:13, Andrew Fish wrote: > >> On Jul 23, 2015, at 5:47 AM, Laszlo Ersek <ler...@redhat.com> wrote: >> >> On 07/23/15 14:44, David Woodhouse wrote: >>> On Thu, 2015-07-23 at 14:41 +0200, Laszlo Ersek wrote: >>>> >>>>> 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). >>> >>> That's viable for LLVM too, right? It should be. >> >> Andrew?... :) >> > > You can add targets to clang to support the ABI you care about. For example > the Xcode target for EFI X64 is -target x86_64-pc-win32-macho, as -arch > x86_64 implies the System V Application Binary Interface. I don’t think that > msabi is supported via the function attribute in clang, it was not a few > years ago when we checked. > > So it is possible to add custom targets to LLVM to support the ABI/image > format you care about. Some one could add -target x86_64-pc-win32-elf for > example. Our firmware team added -target x86_64-pc-win32-macho to the open > source, so anything is possible. The nice thing about LLVM is you can build a > complier that supports the OS ABI and EFI ABI (via a custom target), and not > need a customer complier for EFI. > > Sorry, so hardcoding abi=ms is how LLVM solves the problem.
If I understand correctly, that's exactly what we'd have liked to hear. Is that right, David? The "-mabi=ms" flag would be specific to the GCC toolchains in tools_def.txt. LLVM can take another parameter (or nothing new at all, actually), the point is, the method used with GCC would be identical to the one used with LLVM (just the actual command line options would differ). Thanks! Laszlo ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
