I do not see any issue to add this support to GCC4* except I do not really like the hardcoded path in the compiler name (eg: GCC44_IA32_PREFIX, GCC44_X64_PREFIX). I understand removing the architecture from the CROSS_COMPILE/TOOLS_PFX variable name would prevent to use `build -a ARM -a IA32 -a X64 -p MdePkg/MdePkg.dsc -t GCC`; but I am not sure many people build for all the architectures at the same time. Again, this cross compiler is mainly to ease the use of EDK2 build system. If people still want to build for many architectures they can call the 'build' command line for each of those architecture.
Instead of that: *_GCC44_IA32_OBJCOPY_PATH = DEF(GCC44_IA32_PREFIX)objcopy *_GCC44_IA32_CC_PATH = DEF(GCC44_IA32_PREFIX)gcc *_GCC44_IA32_SLINK_PATH = DEF(GCC44_IA32_PREFIX)ar *_GCC44_IA32_DLINK_PATH = DEF(GCC44_IA32_PREFIX)ld *_GCC44_IA32_ASLDLINK_PATH = DEF(GCC44_IA32_PREFIX)ld *_GCC44_IA32_ASM_PATH = DEF(GCC44_IA32_PREFIX)gcc *_GCC44_IA32_PP_PATH = DEF(GCC44_IA32_PREFIX)gcc *_GCC44_IA32_VFRPP_PATH = DEF(GCC44_IA32_PREFIX)gcc *_GCC44_IA32_ASLCC_PATH = DEF(GCC44_IA32_PREFIX)gcc *_GCC44_IA32_ASLPP_PATH = DEF(GCC44_IA32_PREFIX)gcc *_GCC44_IA32_RC_PATH = DEF(GCC44_IA32_PREFIX)objcopy I would prefer to have something like that: *_GCC44_*_OBJCOPY_PATH = ENV(CROSS_COMPILE)objcopy *_GCC44_*_CC_PATH = ENV(CROSS_COMPILE)gcc *_GCC44_*_SLINK_PATH = ENV(CROSS_COMPILE)ar *_GCC44_*_DLINK_PATH = ENV(CROSS_COMPILE)ld *_GCC44_*_ASLDLINK_PATH = ENV(CROSS_COMPILE)ld *_GCC44_*_ASM_PATH = ENV(CROSS_COMPILE)gcc *_GCC44_*_PP_PATH = ENV(CROSS_COMPILE)gcc *_GCC44_*_VFRPP_PATH = ENV(CROSS_COMPILE)gcc *_GCC44_*_ASLCC_PATH = ENV(CROSS_COMPILE)gcc *_GCC44_*_ASLPP_PATH = ENV(CROSS_COMPILE)gcc *_GCC44_*_RC_PATH = ENV(CROSS_COMPILE)objcopy The reason of CROSS_COMPILE instead of TOOLS_PFX is the variable CROSS_COMPILE is quite common when building packages with cross toolchain. That would reduce the learning curve for new comers. I personally do not know which version of GCC I am using. I would prefer to drop it from the name. I also hate to edit one line into a 5000 files; so I would definitely prefer to move from DEF() to ENV() to define the cross-compiler. Here are some figures: - tools_def.txt: around 5000 lines - 7 toolchains for GCC on Linux: UNIXGCC, GCC44, GCC45, GCC46, ELFGCC, ARMGCC, ARMLINUXGCC (around 700 lines) - 14 toolchains for Visual Studio on Windows: VS2003, VS2003xASL, VS2005, VS2005xASL, VS2005x86, VS2005x86xASL, VS2008, VS2008x86, VS2008xASL, VS2008x86xASL, VS2010, VS2010x86, VS2010xASL, VS2010x86xASL (around 1860 lines) > -----Original Message----- > From: Jordan Justen [mailto:jljus...@gmail.com] > Sent: 28 May 2013 22:32 > To: Andrew Fish > Cc: Olivier Martin; edk2-devel@lists.sourceforge.net; edk2-buildtools- > de...@lists.sourceforge.net > Subject: Re: [edk2-buildtools] [PATCH] BaseTools: Add support for a > CROSS_COMPILE ELFGCC > > On Tue, May 28, 2013 at 12:26 PM, Andrew Fish <af...@apple.com> wrote: > > On May 28, 2013, at 12:10 PM, Jordan Justen <jljus...@gmail.com> > wrote: > >>> Anyway, I am not sure GCC for ARM architectures supports PE/COFF (I > guess > >>> that would 'only' required to add the PE/COFF relocation symbols). > But if > >>> ELFGCC is deprecated for IA32/X64 usage and ARM GCC only supports > ELF > >>> output, do you see any issue to re-use ELFGCC as a cross-toolchain > ? > >> > >> I don't think UEFI supports ELF images for any architecture. For > that > >> reason, I don't think a toolchain named "*ELF*" is a good idea. > > > > Well the ELF bit is important as it has to do with which debugger you > can use. It is the reason we compile to ELF and convert, so we can use > debuggers that know about ELF images. > > > >> Maybe GCCCROSS is a better name? > > > > The problem is a gcc cross compiler could also directly produce a > PE/COFF image, so which tool chain are you talking about? > > > > I vote to leave ELF in the name as it is the debug format being used. > Well I guess we could call it DWARF to be pedantic, but Mach-O uses > DWARF too, so ELF better maps what the debugger knows how to deal with. > > > > If the debugging format is the critical element, then maybe DWARFGCC > is the right answer. I don't agree with this though. It doesn't seem > to follow the model of VS*/GCC*. > > ELFGCC seems additionally problematic given its baggage as a 'hack' > toolchain for UnixPkg. I'd been hoping to deprecate it after > deprecating UnixPkg. (Hmm, probably time to follow through with that.) > > Why this support can't be merged into the actively maintained GCC4* > toolchains? Or, will this introduce too much confusion on these > toolchains? > > I like the CROSS_COMPILE idea, but maybe instead it should be > TOOLS_PFX? > > Although, doesn't CROSS_COMPILE/TOOLS_PFX gloss over the fact that > changing the GCC version like this may mean changes are required to > the tool arguments? > > -Jordan ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
