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.web10.53322.1598880149227264946 for ; Mon, 31 Aug 2020 06:22:29 -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 75F7530E; Mon, 31 Aug 2020 06:22:28 -0700 (PDT) Received: from [192.168.1.80] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9CE333F66F; Mon, 31 Aug 2020 06:22:26 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH V2 2/2] BaseTools: Factorize GCC flags To: Leif Lindholm , Laszlo Ersek 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: Date: Mon, 31 Aug 2020 16:22:21 +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: <20200828191515.GC1191@vanye> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 8/28/20 9:15 PM, Leif Lindholm wrote: > On Fri, Aug 28, 2020 at 18:56:45 +0200, Laszlo Ersek wrote: >>>> Leif, please comment! >>> >>> I did propose reverting it. But I asked for Ard's feedback on the >>> reason for why we had the break in the flags-chain, in case he >>> remembered (and he was on holiday at the time). >>> >>> Basically, I'm wondering whether we're better off changing this >>> behaviour or simply nuking GCC48. >> >> I use GCC48 daily -- it's the system compiler on RHEL7. My laptop runs >> RHEL7 -- I value stability above all. > > That explains why it's still in then :) > > OK, so then cleaning it up would be nice. > Apologies, I had missed this discussion. The reason the GCC flags are defined the way the are is because the GCC4x toolchains for x86 were completely disjoint from the UNIXGCC and other ones that were defined for ARM and IA64. I agree that some cleanup would be nice, but if we are only going to reshuffle tools_def variable assignments, I'm not sure it is worth it. What I would like to see is a bit more structure, and some justification why we are using all those different options, as i am not convinced they are still needed even for GCC as far back as v4.8. Also, even though I understand Laszlo's point about being able to use the RHEL 7 system compiler, using other toolchains is trivially easy with EDK2 (this is the whole point), and mainline EDK2 is arguably a development tree, not a stable production tree for ~5 year old firmware builds, and so I do think we should get rid of GCC48 even before RHEL7 goes EOL. I'd even go so far as suggesting that [at some point in the not too distant future], we rename GCC5 to GCCELFLTO (or something less obnoxious) and phase out all the version based GCC toolchains entirely. We might do the same for CLANG38 (the ELF based one), and depending on whether PE/COFF linker support ever materializes for ARM, have a single Clang+PE based toolchain as well.