On 23 July 2016 at 03:34, Jordan Justen <jordan.l.jus...@intel.com> wrote: > On 2016-07-22 14:46:54, Ard Biesheuvel wrote: >> On 22 July 2016 at 23:19, Jordan Justen <jordan.l.jus...@intel.com> wrote: >> > I think the subject should include be something like "add GCC5 >> > toolchain for X64/AARCH64 with LTO support". >> > >> > On 2016-07-18 05:09:15, Ard Biesheuvel wrote: >> >> This adds support for GCC 5.x in LTO mode for IA32, X64, ARM and >> >> AARCH64. Due to the fact that the GCC project switched to a new >> >> numbering scheme where the first digit is now incremented for every >> >> major release, the new toolchain is simply called 'GCC5', and is >> >> intended to support all GCC v5.x releases. >> >> >> >> Note that this requires the use of an wrapper script, since the GCC >> >> toolchain family usually invokes the linker directly, whereas LTO >> >> requires GCC to be invoked with the linker arguments decorated with >> >> -Wl,xxx prefixes. >> > >> > Does it require the wrapper script? Steven's GCC5 toolchain didn't >> > have it. Also, I was able to convert the GCC49 toolchain to invoke gcc >> > for the linker, rather than ld. Like Steven's GCC5, I had to add -Wl >> > to various flags. Based on this, I was wondering if we could just >> > convert all of the GCC toolchains to invoke gcc for linking. >> > >> >> Steven's patches introduced a new build rule family, which I would >> like to avoid, since it would make GCC:xxx [BuildOptions] sections >> mutually incompatible between GCC44 - GCC49 and GCC5 and later, which >> would probably result in some packages being left behind, and new >> packages not bothering to add support for GCC49 and older. Packages >> supporting both would need to add explicit rules for each GCCx >> version, which is also not great for maintainability. As it turns out, >> we don't have that many DLINK or DLINK2 flags in our various .DSC and >> .INF files, but the ones we do have need to be fixed up at the same >> time that the build rule is updated. >> >> So if nobody is opposed to having a flag day, and switch over all of >> Tianocore to use the 'gcc' executable as the linker, and fix up all >> the fallout in a single patch, I'm up for it. >> > > My first choice would be to convert all the toolchains to use gcc for > linking. I'm not certain it will work for all toolchains though. > > My second choice would be to just add another build rule family. I > think it is less of a hassle than a new wrapper tool. (The issues > Liming raises...) >
Yes, using a wrapper script is a concern. I think adding a build rule family is the best option, but I would prefer to add one in a way that does not split GCC44 - GCC49 and CLANG35 on the one hand and GCC5 and up on the other. So I will rewrite this to move the 'legacy' GCC toolchains to a cloned GCCLD build rule family, and apply subsequent changes to move to 'gcc' as the linker to GCC44 and up _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
