From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.byosoft.com.cn (mail.byosoft.com.cn [58.240.74.243]) by mx.groups.io with SMTP id smtpd.web10.53774.1598881429054109523 for ; Mon, 31 Aug 2020 06:43:51 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=permanent DNS error (domain: byosoft.com.cn, ip: 58.240.74.243, mailfrom: gaoliming@byosoft.com.cn) Received: from DESKTOPS6D0PVI ([116.233.155.155]) (envelope-sender ) by 192.168.6.13 with ESMTP for ; Mon, 31 Aug 2020 21:43:39 +0800 X-WM-Sender: gaoliming@byosoft.com.cn X-WM-AuthFlag: YES X-WM-AuthUser: gaoliming@byosoft.com.cn From: "gaoliming" To: , , "'Leif Lindholm'" , "'Laszlo Ersek'" Cc: "'Pierre Gondois'" , , , "'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> In-Reply-To: Subject: =?UTF-8?B?5Zue5aSNOiBbZWRrMi1kZXZlbF0gW1BBVENIIFYyIDIvMl0gQmFzZVRvb2xzOiBGYWN0b3JpemUgR0NDIGZsYWdz?= Date: Mon, 31 Aug 2020 21:43:39 +0800 Message-ID: <000e01d67f9c$bc0e2e40$342a8ac0$@byosoft.com.cn> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFZh2EPKdL+sXTQdXB1B+gBGeZbuAE1JZjRAefYbz8A9I2hIwJ6oFn8AsrL+5IChoxmowDil6enAqInMvoCKbGRbam/yRPw Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: zh-cn Ard: > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: bounce+27952+64834+4905953+8761045@groups.i= o > =E4=BB=A3=E8=A1=A8 Ard > Biesheuvel > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B48=E6=9C=8831=E6=97=A5= 21:22 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Leif Lindholm ; Laszlo E= rsek > > =E6=8A=84=E9=80=81: Pierre Gondois ; devel@edk2.= groups.io; > bob.c.feng@intel.com; liming.gao@intel.com; Tomas Pilar > ; nd > =E4=B8=BB=E9=A2=98: Re: [edk2-devel] [PATCH V2 2/2] BaseTools: Factorize= GCC flags >=20 > 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 run= s > >> RHEL7 -- I value stability above all. > > > > That explains why it's still in then :) > > > > OK, so then cleaning it up would be nice. > > >=20 > Apologies, I had missed this discussion. >=20 > 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. >=20 > 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. >=20 > 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. >=20 I have the same feeling on VS tool chain. Now, very old VS2008 tool chain = is still in tools_def.txt. > 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. >=20 This is a good idea to unify tool chain. But, the impact is big.=20 To keep combability, GCC5 and GCCELFLTO can be defined together and share = the same setting.=20 Thanks Liming >=20 >=20