From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web12.54583.1598884677149141625 for ; Mon, 31 Aug 2020 07:37:57 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5F0A21FB; Mon, 31 Aug 2020 07:37:56 -0700 (PDT) Received: from [192.168.1.205] (unknown [10.37.8.74]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C43D93F68F; Mon, 31 Aug 2020 07:37:53 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH V2 2/2] BaseTools: Factorize GCC flags To: Laszlo Ersek , Leif Lindholm Cc: Pierre Gondois , "devel@edk2.groups.io" , "bob.c.feng@intel.com" , "liming.gao@intel.com" , Tomas Pilar , nd References: <20200707083522.138944-1-pierre.gondois@arm.com> <20200707083522.138944-3-pierre.gondois@arm.com> <879fda8a-37bd-a902-6028-c879ed37fa28@redhat.com> <22b94ad5-db03-7280-4032-6ebf8dfc1d49@redhat.com> <518916e0-53cc-732b-cf1b-1e1b8d10a3b3@redhat.com> <20200827152511.GX1191@vanye> <42cb48da-b932-7006-475b-d5259bcd0d8a@redhat.com> <20200828191515.GC1191@vanye> From: "Ard Biesheuvel" Message-ID: <75feab5d-c7c9-972f-4201-0dd6c4280569@arm.com> Date: Mon, 31 Aug 2020 17:37:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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.