Re: [edk2] BaseTools: Add MINGW tool chain

Subject: Re: [edk2] BaseTools: Add MINGW tool chain

From: "Gao, Liming" <liming.gao@intel.com>

To: Scott Duplichan <scott@notabs.org>, 'Jordan Justen' <jljusten@gmail.com>, "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>

Date: 2014-10-16 13:54:19

Scott:
  I agree it better than MINGW in windows. Now, I have some questions.
  1. To use GCC49 in windows, user has to build GCC49 compiler to windows exe files first? Could user directly download from the public website?  BTW: I download files from http://notabs.org/uefi/xgcc/. But I can't extract them. Could you help check it?
  2. This tool chain should have the same image size to the native GCC49 in Linux, right?  
  3. Have you verified the functionality, such as OVMF platform boot?

  For this patch, I think we can update it with the minimal impact to Linux user. The below patch is provided. Linux user doesn't need to set GCC49_BIN, GCC49_DLL env, because /usr/bin/ is the default system PATH. Windows user need to set GCC49_BIN, GCC49_DLL and IASL_PREFIX env to use this tool chain. 
Index: Conf/tools_def.template
===================================================================
--- Conf/tools_def.template	(revision 16124)
+++ Conf/tools_def.template	(working copy)
@@ -182,8 +182,8 @@
 DEFINE GCC48_IA32_PREFIX       = /usr/bin/
 DEFINE GCC48_X64_PREFIX        = /usr/bin/
 
-DEFINE GCC49_IA32_PREFIX       = /usr/bin/
-DEFINE GCC49_X64_PREFIX        = /usr/bin/
+DEFINE GCC49_IA32_PREFIX       = ENV(GCC49_BIN)
+DEFINE GCC49_X64_PREFIX        = ENV(GCC49_BIN)
 
-*_GCC49_*_MAKE_PATH                    = make
+*_GCC49_*_MAKE_PATH                    = DEF(GCC49_BIN)make
+*_GCC49_*_*_DLL                        = DEF(GCC49_DLL)
 *_GCC49_*_ASL_PATH                     = DEF(UNIX_IASL_BIN)

Thanks
Liming
-----Original Message-----
From: Scott Duplichan [mailto:scott@notabs.org] 
Sent: Thursday, October 16, 2014 12:26 PM
To: 'Jordan Justen'; edk2-devel@lists.sourceforge.net; Gao, Liming
Subject: RE: [edk2] BaseTools: Add MINGW tool chain

Jordan Justen [mailto:jljusten@gmail.com] wrote:

]What does this buy us?
]
]Can't the GCC44-49 toolchains be used under a msys bash shell to ]achieve basically the same thing without adding a new toolchain?

Using the existing gcc tool chain definition for building EDK2 from Windows using gcc is a good idea. Building a gcc cross compiler that runs on Windows but generates Linux code makes it easy. Here is an experimental Windows hosted gcc tool chain that targets x86_64-linux-gnu, just like the native Linux compiler does.
It is built from unmodified gcc 4.9.1 source code:

http://notabs.org/uefi/xgcc/

One archive contains binaries and the other has detailed instructions for building the tool chain from scratch on Windows. To use it, extract to the build machine and point environment variable GCC49 to them. Then apply the patch below and build from the Windows CMD box.
The binaries are Win32 so they should work on both Win32 and Win64.
They are tested on Windows 7 x64. A test of 18 builds all pass:

build.exe -p D:\uefi\buildtest-013\edk2\OvmfPkg\OvmfPkgX64.dsc -b DEBUG -t GCC49 -n 16 -a X64 -DSECURE_BOOT_ENABLE -DFD_SIZE_2MB                                  
build.exe -p D:\uefi\buildtest-013\edk2\OvmfPkg\OvmfPkgX64.dsc -b RELEASE -t GCC49 -n 16 -a X64 -DSECURE_BOOT_ENABLE -DFD_SIZE_2MB                                  
build.exe -p D:\uefi\buildtest-013\edk2\OvmfPkg\OvmfPkgIA32.dsc -b DEBUG -t GCC49 -n 16 -a IA32 -DSECURE_BOOT_ENABLE -DFD_SIZE_2MB                                  
build.exe -p D:\uefi\buildtest-013\edk2\OvmfPkg\OvmfPkgIA32.dsc -b RELEASE -t GCC49 -n 16 -a IA32 -DSECURE_BOOT_ENABLE -DFD_SIZE_2MB                                  
build.exe -p D:\uefi\buildtest-013\edk2\OvmfPkg\OvmfPkgIA32X64.dsc -b DEBUG -t GCC49 -n 16 -a IA32 -a X64 -DSECURE_BOOT_ENABLE -DFD_SIZE_2MB                                  
build.exe -p D:\uefi\buildtest-013\edk2\OvmfPkg\OvmfPkgIA32X64.dsc -b RELEASE -t GCC49 -n 16 -a IA32 -a X64 -DSECURE_BOOT_ENABLE -DFD_SIZE_2MB                                  
build.exe -p D:\uefi\buildtest-013\edk2\AppPkg\AppPkg.dsc -b DEBUG -t GCC49 -n 16 -a X64                                  
build.exe -p D:\uefi\buildtest-013\edk2\AppPkg\AppPkg.dsc -b RELEASE -t GCC49 -n 16 -a X64                                  
build.exe -p D:\uefi\buildtest-013\edk2\AppPkg\AppPkg.dsc -b DEBUG -t GCC49 -n 16 -a IA32                                  
build.exe -p D:\uefi\buildtest-013\edk2\AppPkg\AppPkg.dsc -b RELEASE -t GCC49 -n 16 -a IA32                                  
build.exe -p D:\uefi\buildtest-013\edk2\IntelFspPkg\IntelFspPkg.dsc -b DEBUG -t GCC49 -n 16 -a IA32                                  
build.exe -p D:\uefi\buildtest-013\edk2\IntelFspPkg\IntelFspPkg.dsc -b RELEASE -t GCC49 -n 16 -a IA32                                  
build.exe -p D:\uefi\buildtest-013\edk2\DuetPkg\DuetPkgX64.dsc -b DEBUG -t GCC49 -n 16 -a X64                                  
build.exe -p D:\uefi\buildtest-013\edk2\DuetPkg\DuetPkgIA32.dsc -b DEBUG -t GCC49 -n 16 -a IA32                                  
build.exe -p D:\uefi\buildtest-013\edk2\ShellPkg\ShellPkg.dsc -b DEBUG -t GCC49 -n 16 -a X64                                  
build.exe -p D:\uefi\buildtest-013\edk2\ShellPkg\ShellPkg.dsc -b RELEASE -t GCC49 -n 16 -a X64                                  
build.exe -p D:\uefi\buildtest-013\edk2\ShellPkg\ShellPkg.dsc -b DEBUG -t GCC49 -n 16 -a IA32                                  
build.exe -p D:\uefi\buildtest-013\edk2\ShellPkg\ShellPkg.dsc -b RELEASE -t GCC49 -n 16 -a IA32                                  

The changes to EDK2 for supporting this tool chain are small. Just replace a hard coded path with an environment variable reference and add a DLL path:

Index: BaseTools/Conf/tools_def.template ===================================================================
--- BaseTools/Conf/tools_def.template	(revision 16219)
+++ BaseTools/Conf/tools_def.template	(working copy)
@@ -182,8 +182,10 @@
 DEFINE GCC48_IA32_PREFIX       = /usr/bin/
 DEFINE GCC48_X64_PREFIX        = /usr/bin/
 
-DEFINE GCC49_IA32_PREFIX       = /usr/bin/
-DEFINE GCC49_X64_PREFIX        = /usr/bin/
+DEFINE GCC49_BIN               = ENV(GCC49)/bin/
+DEFINE GCC49_DLL               = ENV(GCC49)/dll/
+DEFINE GCC49_IA32_PREFIX       = DEF(GCC49_BIN)
+DEFINE GCC49_X64_PREFIX        = DEF(GCC49_BIN)
 
 DEFINE UNIX_IASL_BIN           = ENV(IASL_PREFIX)iasl
 DEFINE WIN_ASL_BIN_DIR         = C:\ASL
@@ -4489,8 +4491,9 @@
 ####################################################################################
 *_GCC49_*_*_FAMILY               = GCC
 
-*_GCC49_*_MAKE_PATH                    = make
-*_GCC49_*_ASL_PATH                     = DEF(UNIX_IASL_BIN)
+*_GCC49_*_*_DLL                        = DEF(GCC49_DLL)
+*_GCC49_*_MAKE_PATH                    = DEF(GCC49_BIN)make
+*_GCC49_*_ASL_PATH                     = ENV(UEFI_BUILD_TOOLS)/ASL/iasl
 
 *_GCC49_*_PP_FLAGS                     = DEF(GCC_PP_FLAGS)
 *_GCC49_*_ASLPP_FLAGS                  = DEF(GCC_ASLPP_FLAGS)
Index: BaseTools/Source/Python/AutoGen/GenMake.py
===================================================================
--- BaseTools/Source/Python/AutoGen/GenMake.py	(revision 16219)
+++ BaseTools/Source/Python/AutoGen/GenMake.py	(working copy)
@@ -679,7 +679,11 @@
                     NewFile = self.PlaceMacro(str(F), self.Macros)
                     # In order to use file list macro as dependency
                     if T.GenListFile:
-                        self.ListFileMacros[T.ListFileMacro].append(str(F))
+                        # gnu tools need forward slash path separater, even on Windows
+                        if self.PlatformInfo.ToolChainFamily in ('GCC'):
+                            self.ListFileMacros[T.ListFileMacro].append(str(F).replace ('\\', '/'))
+                        else:
+                            
+ self.ListFileMacros[T.ListFileMacro].append(str(F))
                         self.FileListMacros[T.FileListMacro].append(NewFile)
                     elif T.GenFileListMacro:
                         self.FileListMacros[T.FileListMacro].append(NewFile)

 
Though the echo command exists for both Windows and Linux, it is built in as part of cmd.exe on Windows and cannot be launched as an objcopy stub like on Linux. To work around that difference, I added an echo.exe to the Windows tool chain. A better work around might be to split Command.GCC in build_rule into Command.GCC and Command.GCC_IPF. Apparently only IPF needs the symrename step.

This patch alone will break the Linux gcc build. But hopefully all that is needed to restore the Linux build is to have edksetup.sh set environment variable GCC49 to /usr if it is not already set.

I think this type of Windows hosted gcc tool chain will end up being the preferred method of building with gcc from Windows.
It may or may not make sense to add MINGW in addition to this.

Thanks,
Scott

]I would rather see us remove the similar 'CYGGCC' toolchain, but it ]seems that once we add a toolchain we can never remove it. (See also, ]ELFGCC, which I think should be deprecated as well.) ] ]-Jordan

On Mon, Oct 13, 2014 at 10:33 PM, Gao, Liming  wrote:
> Scott:
>   I try using MINGW Make, it can pass build. The change is
> +*_MINGW_*_MAKE_PATH          = ENV(MS_MISC_BIN)\nmake.exe
> +*_MINGW_*_MAKE_FLAGS         = /nologo
> ==>
> *_MINGW_*_MAKE_PATH          = DEF(MINGW_BINIA32)make
> *_MINGW_*_MAKE_FLAGS        =
>
>   And, I try X64 build and find the error message that "rem" can't be found.  Then, I remove SYMRENAME step and get build pass. The change is:
> Tools_def.txt
> *_MINGW_*_*_BUILDRULEFAMILY  = MINGWGCC
>
> Build_rule.txt
>     
>         "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
>
> Thanks
> Liming
> -----Original Message-----
> From: Scott Duplichan [mailto:scott@notabs.org]
> Sent: Friday, October 10, 2014 2:08 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] BaseTools: Add MINGW tool chain
>
> Gao, Liming [mailto:liming.gao@intel.com] wrote:
>
> ]Scott:
> ] Does MINGW base on GCC? If yes, is it similar to which version GCC?
> ] If I verify the code in MINGW tool chain, do I need to verify it in ] native GCC tool chain?
>
> Hello Liming,
> The MINGW compilers are built from the same gcc source code that the Linux versions are built from. I have been testing with gcc 4.9.0. A build from source code test of gcc 4.8.2 works. The same build script supports versions back to 4.6.2, so those should be easy to build too.
>
> Your question about verifying gcc builds using MINGW is a good one.
> I think the errors/warnings would match 99%. The reason they could differ is that sizeof (long) is 4 for MINGW, yet I believe it is 8 for Linux gcc builds. This difference would not affect most EDK2 code because EDK2 uses UINT32, UINT64, etc. But some of the ported code uses int, long, etc. So warnings from that ported code could differ for MINGW and Linux builds of the same gcc compiler.
>
> ] For size issue, have you compared the size between native GCC tool ] chain and MINGW tool chain?
>
> I have not done that, but I will do it tomorrow. I believe the MINGW gcc compiler will generate the same code as its Linux counterpart, except for cases where the difference in sizeof (long) is a factor.
> There can also be some differences due to non-code sections of the image. I was finally able to strip enough non-code sections to get all of the 18 test builds I ran to pass using MINGW/Windows.
>
> Gcc built EDK2 modules are much bigger than their Microsoft built counterparts. This is true for MINGW gcc builds, and presumable true for Linux gcc builds. Gcc code generation and size optimization is good. The problem is that EDK2 is not yet using the gcc link time optimization feature. Link time code generation and optimization is especially important for EDK2. With the Microsoft compiler's link time code generation, a fixed at build time PCD acts like a defined constant. A large section of code inside an "if (MyPCD)" can be completely removed if MyPCD is zero. With gcc, the compiler is generating code to check the PCD at run time using a function call, and that prevents removal of the unneeded code. The gcc link time code generation feature is working well enough for use on large projects such as Mozilla Firefox, so it should be usable for EDK2. I wanted to test it, but it turns out this is not possible using Windows builds of gcc. The problem is that a gcc 'linker plugin' feature has not been ported for use on Windows. The linker plugin is needed for link time code generation when static libraries are used. Without it, link time cod generation works only for object files. The EDK2 build makes heavy use of static libraries, so I think the linker plugin is essential.
> For now, Linux will be the only way to test link time optimization.
>
> ] For Nasm issue in BaseLib, MINGW output is COFF format. So, NASM_FLAGS ] should be -f win32 and -f win64. I just try them and pass build.
>
> Thank you for debugging this problem. Your fix works perfectly for me too.
>
> ] For tool_def.txt, on MAKE and RC path, could we directly use make and ] objcopy from MINGW like the native GCC tool chain? If so, MINGW is a ] standalone tool chain.
>
> In theory, the answer is yes. MINGW has its own resource compiler, windres.exe. Make is the big challenge. I am not much of a make file expert, so it will take a while to get it going. One approach is to build EDK2 from an msys2 bash prompt. This is how gcc and other gnu projects can be built from Windows. I made a brief try using this method but encountered a python crash early on. Running the MINGW build of gnu make from cmd.exe is another possibility. A quick test using this method ends with an "No rule to make target"
> error. I need to compare the make debug output from Linux and Windows.
>
> Thanks,
> Scott
>
> ]
> ]+*_MINGW_*_MAKE_PATH          = ENV(MS_MISC_BIN)\nmake.exe
> ]+*_MINGW_IA32_RC_PATH         = ENV(MS_MISC_BIN)\rc.exe
> ]
> ]Thanks
> ]Liming
>
>
> -----Original Message-----
> From: Scott Duplichan [mailto:scott@notabs.org]
> Sent: Saturday, October 04, 2014 11:42 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] BaseTools: Add MINGW tool chain
>
> Nikolai Saoukh [mailto:nms@otdel-1.org] wrote:
>
> ]I was under impression that mingw-win64 can be used for X64 AND IA32 builds.
>
> You are right. Thanks for pointing that out. The revised email and patch follows.
> I also added the requirement for an environment variable pointing to Microsoft nmake.exe and rc.exe. Still needed is nasm.exe and iasl.exe, but these work the same as with Microsoft tool chains.
> --
>
> Here is a work in progress patch for those building X64 or IA32 targets from Windows. It allows building with gcc instead of a Microsoft compiler.
> Building has been tested with Windows 7 x64 using MINGW archives from 
> http://www.drangon.org/mingw/ or 
> http://sourceforge.net/projects/mingw-w64-dgn/files/mingw-w64/
>
> Unpack mingw-w64-bin-x86_64-20140425.7z and set environment variable
> MINGW64 to its path. Also set environment variable MINGW32 to its path.
> Set environment variable MS_MISC_BIN to a directory containing Microsoft nmake.exe and rc.exe. For example, the bin\x86 directory of DDK-7600:
> http://www.microsoft.com/en-us/download/details.aspx?id=11800.
>
> Apply the patch then build using -t MINGW. It's that easy. No unix shell port is involved. Just build from a cmd.exe prompt as normal.
> Because mingw requires no install or setup, your registry, path and other environment variables are unaffected.
>
> The MINGW port of gcc brings C99 support to those using Windows to develop EDK2 code. Wouldn't it be nice if one day UEFI could drop support for non-C99 compilers so that C99 features could be used in the code? There is actually a lot of work to be done before gcc could replace Microsoft tools. One problem is that some UEFI source level debuggers understand only Microsoft debug information. Another problem is that right now gcc is producing bigger code. Getting gcc link time optimization working may solve this problem. Build speed with MINGW is not quite as fast as with Microsoft tools, but it is reasonable.
> For example, a test of 18 builds that takes 523 seconds using VS2008 takes 694 seconds using MINGW.
>
> Index: BaseTools/Conf/tools_def.template ===================================================================
> --- BaseTools/Conf/tools_def.template   (revision 16195)
> +++ BaseTools/Conf/tools_def.template   (working copy)
> @@ -4815,6 +4815,103 @@
>
>  
> ######################################################################
> ##############
>  #
> +# Mingw GCC And Intel ACPI Compiler
> +#
> +####################################################################################
> +#   MINGW        - MINGW GCC
> +#   ASL           - Intel ACPI Source Language Compiler (iasl.exe)
> +*_MINGW_*_*_FAMILY           = GCC
> +
> +DEFINE MINGW_BINIA32         = ENV(MINGW32)\bin\
> +DEFINE MINGW_BINX64          = ENV(MINGW64)\bin\
> +
> +*_MINGW_*_MAKE_PATH          = ENV(MS_MISC_BIN)\nmake.exe
> +*_MINGW_*_ASL_PATH           = DEF(DEFAULT_WIN_ASL_BIN)
> +*_MINGW_IA32_DLINK_FLAGS     = DEF(GCC_IA32_X64_DLINK_COMMON) -m i386pe  --entry _$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map --image-base=0 --strip-all
> +*_MINGW_X64_DLINK_FLAGS      = DEF(GCC_IA32_X64_DLINK_COMMON) -m i386pep --entry  $(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map --image-base=0 --strip-all
> +*_MINGW_IA32_ASLDLINK_FLAGS  = DEF(GCC_IA32_X64_DLINK_COMMON) -m i386pe  --entry _ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) --strip-all
> +*_MINGW_X64_ASLDLINK_FLAGS   = DEF(GCC_IA32_X64_DLINK_COMMON) -m i386pep --entry  ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) --strip-all
> +
> +*_MINGW_*_MAKE_FLAGS         = /nologo
> +*_MINGW_*_ASL_FLAGS          = DEF(DEFAULT_WIN_ASL_FLAGS)
> +*_MINGW_*_ASL_OUTFLAGS       = DEF(DEFAULT_WIN_ASL_OUTFLAGS)
> +
> +##################
> +# IA32 definitions
> +##################
> +*_MINGW_IA32_CC_PATH         = DEF(MINGW_BINIA32)gcc
> +*_MINGW_IA32_SLINK_PATH      = DEF(MINGW_BINIA32)ar
> +*_MINGW_IA32_DLINK_PATH      = DEF(MINGW_BINIA32)ld
> +*_MINGW_IA32_ASM_PATH        = DEF(MINGW_BINIA32)gcc
> +*_MINGW_IA32_PP_PATH         = DEF(MINGW_BINIA32)gcc
> +*_MINGW_IA32_APP_PATH        = DEF(MINGW_BINIA32)gcc
> +*_MINGW_IA32_VFRPP_PATH      = DEF(MINGW_BINIA32)gcc
> +*_MINGW_IA32_ASLCC_PATH      = DEF(MINGW_BINIA32)gcc
> +*_MINGW_IA32_ASLPP_PATH      = DEF(MINGW_BINIA32)gcc
> +*_MINGW_IA32_ASLDLINK_PATH   = DEF(MINGW_BINIA32)ld
> +*_MINGW_IA32_RC_PATH         = ENV(MS_MISC_BIN)\rc.exe
> +*_MINGW_IA32_OBJCOPY_PATH    = DEF(MINGW_BINIA32)objcopy
> +*_MINGW_IA32_SYMRENAME_PATH  = DEF(MINGW_BINIA32)objcopy
> +
> +*_MINGW_IA32_CC_FLAGS        = DEF(GCC_ALL_CC_FLAGS) -m32 -Os -malign-double -mno-stack-arg-probe -fomit-frame-pointer -Wno-error
> +*_MINGW_IA32_PP_FLAGS        = DEF(GCC_PP_FLAGS) -m32
> +*_MINGW_IA32_ASM_FLAGS       = DEF(GCC_ASM_FLAGS) -m32
> +*_MINGW_IA32_ASLPP_FLAGS     = DEF(GCC_ASLPP_FLAGS) -m32
> +*_MINGW_IA32_ASLCC_FLAGS     = DEF(GCC_ASLCC_FLAGS) -m32
> +*_MINGW_IA32_VFRPP_FLAGS     = DEF(GCC_VFRPP_FLAGS) -m32
> +*_MINGW_IA32_APP_FLAGS       = -m32
> +*_MINGW_IA32_OBJCOPY_FLAGS   = --remove-section .idata --remove-section .edata
> +*_MINGW_IA32_SYMRENAME_FLAGS = --remove-section .idata --remove-section .edata
> +*_MINGW_IA32_RC_FLAGS        = DEF(GCC_IA32_RC_FLAGS)
> +*_MINGW_IA32_NASM_FLAGS      = -f elf32
> +
> +##################
> +# X64 definitions
> +##################
> +*_MINGW_X64_CC_PATH          = DEF(MINGW_BINX64)gcc
> +*_MINGW_X64_SLINK_PATH       = DEF(MINGW_BINX64)ar
> +*_MINGW_X64_DLINK_PATH       = DEF(MINGW_BINX64)ld
> +*_MINGW_X64_ASM_PATH         = DEF(MINGW_BINX64)gcc
> +*_MINGW_X64_PP_PATH          = DEF(MINGW_BINX64)gcc
> +*_MINGW_X64_APP_PATH         = DEF(MINGW_BINX64)gcc
> +*_MINGW_X64_VFRPP_PATH       = DEF(MINGW_BINX64)gcc
> +*_MINGW_X64_ASLCC_PATH       = DEF(MINGW_BINX64)gcc
> +*_MINGW_X64_ASLPP_PATH       = DEF(MINGW_BINX64)gcc
> +*_MINGW_X64_ASLDLINK_PATH    = DEF(MINGW_BINX64)ld
> +*_MINGW_IA32_RC_PATH         = ENV(MS_MISC_BIN)\rc.exe
> +*_MINGW_X64_OBJCOPY_PATH     = DEF(MINGW_BINX64)objcopy
> +*_MINGW_X64_SYMRENAME_PATH   = rem
> +
> +*_MINGW_X64_CC_FLAGS         = DEF(GCC_X64_CC_FLAGS) -m64 -Wno-error
> +*_MINGW_X64_PP_FLAGS         = DEF(GCC_PP_FLAGS) -m64
> +*_MINGW_X64_ASM_FLAGS        = DEF(GCC_ASM_FLAGS) -m64
> +*_MINGW_X64_ASLPP_FLAGS      = DEF(GCC_ASLPP_FLAGS) -m64
> +*_MINGW_X64_ASLCC_FLAGS      = DEF(GCC_ASLCC_FLAGS) -m64
> +*_MINGW_X64_VFRPP_FLAGS      = DEF(GCC_VFRPP_FLAGS) -m64
> +*_MINGW_X64_APP_FLAGS        = -m64
> +*_MINGW_X64_OBJCOPY_FLAGS    = --remove-section .pdata --remove-section .xdata
> +*_MINGW_X64_SYMRENAME_FLAGS  = Symbol renaming not needed for
> +*_MINGW_X64_RC_FLAGS         = DEF(GCC_X64_RC_FLAGS)
> +*_MINGW_X64_NASM_FLAGS       = -f elf64
> +
> +##################
> +# EBC definitions
> +##################
> +*_MINGW_EBC_*_FAMILY      = INTEL
> +
> +*_MINGW_EBC_PP_PATH       = DEF(EBC_BIN)\iec.exe
> +*_MINGW_EBC_CC_PATH       = DEF(EBC_BIN)\iec.exe
> +*_MINGW_EBC_DLINK_PATH    = DEF(EBC_BIN)\link.exe
> +*_MINGW_EBC_SLINK_PATH    = DEF(EBC_BIN)\link.exe
> +*_MINGW_EBC_VFRPP_PATH    = DEF(EBC_BIN)\iec.exe
> +*_MINGW_EBC_RC_PATH       = ENV(MS_MISC_BIN)\rc.exe
> +
> +*_MINGW_EBC_CC_FLAGS      = /nologo /c /WX /W3 /FIAutoGen.h /D$(MODULE_ENTRY_POINT)=$(ARCH_ENTRY_POINT)
> +*_MINGW_EBC_SLINK_FLAGS   = /lib /NOLOGO /MACHINE:EBC
> +*_MINGW_EBC_DLINK_FLAGS   = "C:\Program Files\Intel\EBC\Lib\EbcLib.lib" /NOLOGO /NODEFAULTLIB /MACHINE:EBC /OPT:REF /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /ALIGN:32 /DRIVER
> +
> +#####################################################################
> +##
> +#############
> +#
>  # Elf GCC - This configuration is used to compile on Linux boxes to produce elf
>  #           binaries.
>  #
> Index: BaseTools/Source/Python/AutoGen/GenMake.py
> ===================================================================
> --- BaseTools/Source/Python/AutoGen/GenMake.py  (revision 16195)
> +++ BaseTools/Source/Python/AutoGen/GenMake.py  (working copy)
> @@ -679,7 +679,11 @@
>                      NewFile = self.PlaceMacro(str(F), self.Macros)
>                      # In order to use file list macro as dependency
>                      if T.GenListFile:
> -                        self.ListFileMacros[T.ListFileMacro].append(str(F))
> +                        # gnu tools need forward slash path separater, even on Windows
> +                        if self.PlatformInfo.ToolChainFamily in ('GCC'):
> +                            self.ListFileMacros[T.ListFileMacro].append(str(F).replace ('\\', '/'))
> +                        else:
> +
> + self.ListFileMacros[T.ListFileMacro].append(str(F))
>                          self.FileListMacros[T.FileListMacro].append(NewFile)
>                      elif T.GenFileListMacro:
>                          
> self.FileListMacros[T.FileListMacro].append(NewFile)
> Index: MdePkg/Library/BaseLib/BaseLib.inf
> ===================================================================
> --- MdePkg/Library/BaseLib/BaseLib.inf  (revision 16195)
> +++ MdePkg/Library/BaseLib/BaseLib.inf  (working copy)
> @@ -252,7 +252,7 @@
>    Ia32/DisableCache.asm | INTEL
>
>    Ia32/GccInline.c | GCC
> -  Ia32/Thunk16.nasm | GCC
> +  Ia32/Thunk16.S | GCC
>    Ia32/EnableDisableInterrupts.S | GCC
>    Ia32/EnablePaging64.S | GCC
>    Ia32/DisablePaging32.S | GCC
> @@ -405,7 +405,7 @@
>    X86DisablePaging64.c
>    X86DisablePaging32.c
>    X64/GccInline.c | GCC
> -  X64/Thunk16.nasm | GCC
> +  X64/Thunk16.S | GCC
>    X64/SwitchStack.S | GCC
>    X64/SetJump.S | GCC
>    X64/LongJump.S | GCC
> Index: StdLib/EfiSocketLib/EfiSocketLib.inf
> ===================================================================
> --- StdLib/EfiSocketLib/EfiSocketLib.inf        (revision 16195)
> +++ StdLib/EfiSocketLib/EfiSocketLib.inf        (working copy)
> @@ -68,3 +68,6 @@
>    gEfiUdp6ServiceBindingProtocolGuid
>    gEfiSocketProtocolGuid
>    gEfiSocketServiceBindingProtocolGuid
> +
> +[BuildOptions]
> +  GCC:*_MINGW_*_CC_FLAGS = -D__attribute__(weak)=
> Index: StdLib/Include/X64/machine/limits.h
> ===================================================================
> --- StdLib/Include/X64/machine/limits.h (revision 16195)
> +++ StdLib/Include/X64/machine/limits.h (working copy)
> @@ -2,7 +2,7 @@
>
>  #define __POINTER_BIT   64
>
> -#if defined(__GNUC__)
> +#if defined(__GNUC__) && !defined(_WIN32)
>  #if __GNUC_PREREQ__(4,4)
>    #define __LONG_BIT      64
>
> --
> Thanks,
> Scott
> ----------------------------------------------------------------------
> -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog 
> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI 
> DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download 
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with 
> EventLog Analyzer 
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
> clktrk _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> ----------------------------------------------------------------------
> -------- Meet PCI DSS 3.0 Compliance Requirements with EventLog 
> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI 
> DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download 
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with 
> EventLog Analyzer 
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
> clktrk _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> ----------------------------------------------------------------------
> -------- Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel