Re: [edk2-devel] [PATCH V2 2/2] BaseTools: Factorize GCC flags

["Ard Biesheuvel" <ard.biesheuvel@arm.com>]

On 8/31/20 4:03 PM, Laszlo Ersek wrote:
> On 08/31/20 15:22, Ard Biesheuvel wrote:
> 
>> mainline EDK2 is arguably a development tree
> 
> I agree.
> 
>> not a stable production tree for ~5 year old firmware builds
> 
> I agree with that too.
> 
> But I don't think GCC48 is "holding back" edk2. I don't know of a
> firmware feature that suffers because I'd like to be able to build the
> tree with GCC48.
> 

True.

> (LTO is not a firmware feature; and NOOPT builds, which are important,
> don't / shouldn't enable LTO anyway.)
> 
> I do agree that maintaining the BaseTools stuff that's related to GCC48
> is a burden, technically speaking. Is it a big burden? Should I attempt
> to handle related issues?
> 

Not necessarily. For obvious reasons, my mental picture of the 
historical situation is more clear when it comes to ARM, and GCC48 is 
the last version that uses the large code model, and which shipped with 
a version of binutils that was buggy, requiring extra restrictions wrt 
binary layout in GenFw) [which brings me to another GCC toolchain 
versioning issue, which is that binutils is released on a separate 
schedule, and the '48' in GCC48 does not clearly specify the binutils 
version]

Not sure how Leif feels about this, but i wouldn't mind retaining GCC48 
support only for IA32/X64. Or alternatively, make it a per-platform 
decision (which it ultimately is anyway, given that every platform ships 
with platform specific code that could have issues with older toolchains)

> Official Software Collections / Developer Toolset add-ons exist for
> RHEL7:
> 
>    https://developers.redhat.com/products/developertoolset/overview
>    https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/9/html/user_guide/chap-red_hat_developer_toolset#sect-Red_Hat_Developer_Toolset-Compatibility
> 
> I've played with them in the past. They weren't a good fit for me, as I
> recall. Anyway, I can check them out again, if I must.
> 
>> and so I do think we should get rid of GCC48 even before RHEL7 goes
>> EOL.
> 
> We might want to explore the Debian / Ubuntu status too (LTS).
> 

Agreed. But one final remark on the distro/system toolchain situation: 
distros have good reasons for sticking with a single GCC version to 
build the world, but I wonder if any of them hold for UEFI builds such 
as OVMF, which runs entirely in its own context, and is mangled by GenFw 
so the ELF objects are never even consumed directly. So as I see it, the 
*only* benefit of retaining GCC48 support is for the convenience of 
developers that use 'mature' distros like RHEL 7 and prefer to use the 
compiler that happens to be installed. I am not saying this is not a 
good enough reason, just something we have to realize.