Re: 回复: [edk2-devel] [PATCH v2 00/13] BaseTools,CryptoPkg,MdePkg,OvmfPkg: Delete CLANG35,CLANG38,GCC48,GCC49, rename GCC5 to GCC, update CLANGDWARF, delete VS 2008-2013, EBC

["Michael D Kinney" <michael.d.kinney@intel.com>]

Are the same issue(s) found with GCC5 with -b NOOPT?

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ard Biesheuvel
> Sent: Monday, April 3, 2023 6:05 AM
> To: devel@edk2.groups.io; quic_llindhol@quicinc.com
> Cc: Gerd Hoffmann <kraxel@redhat.com>; rebecca@bsdio.com; Pedro Falcato <pedro.falcato@gmail.com>; Gao, Liming
> <gaoliming@byosoft.com.cn>; Oliver Smith-Denny <osd@smith-denny.com>; Jiang, Guomin <guomin.jiang@intel.com>; Lu, Xiaoyu1
> <xiaoyu1.lu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Ard Biesheuvel
> <ardb+tianocore@kernel.org>; Justen, Jordan L <jordan.l.justen@intel.com>; Feng, Bob C <bob.c.feng@intel.com>; Andrew Fish
> <afish@apple.com>; Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: Re: 回复: [edk2-devel] [PATCH v2 00/13] BaseTools,CryptoPkg,MdePkg,OvmfPkg: Delete CLANG35,CLANG38,GCC48,GCC49,
> rename GCC5 to GCC, update CLANGDWARF, delete VS 2008-2013, EBC
> 
> On Mon, 3 Apr 2023 at 14:15, Leif Lindholm <quic_llindhol@quicinc.com> wrote:
> >
> > On Mon, Apr 03, 2023 at 13:55:19 +0200, Ard Biesheuvel wrote:
> > > I agree that we should either support a toolchain (and have CI
> > > coverage for it) or not, in which case we should just remove it.
> > >
> > > However, the issues being reported are specific to SEV-SNP and TDX,
> > > which implies that they are specific to OVMF. And actually, the
> > > reported issue at
> > >
> > > OvmfPkg/Library/CcExitLib/CcExitVcHandler.c:1358:10:
> > > error: ‘XCr0’ may be used uninitialized [-Werror=maybe-uninitialized]
> > >
> > > seems to be a valid concern.
> > >
> > > So the point I am making is that OVMF gets a lot of attention in the
> > > open source project, but in the wider ecosystem, there are many
> > > platforms relying on this code base that don't incorporate the Coco
> > > components at all, so whether OVMF currently builds with GCC49 is not
> > > 100% relevant.
> > >
> > > So I am leaning towards retaining GCC49 as GCCNOLTO, and getting some
> > > coverage for it in CI, as we occasionally get useful diagnostics out
> > > of it. But I am not going to fight any battles over it - I rarely use
> > > it myself, and so I will not miss it when it's gone.
> >
> > I agree with all aspects of this statement. I would *prefer* to keep
> > it as a canary - with CI.
> >
> 
> Cheers.
> 
> And interestingly, GCC49 appears to spot an issue introduced with commit
> 
> commit a7fcab7aa3de338c02e61fd891610b1ec926e6c8
> Author: Hua Ma <hua.ma@intel.com>
> Date:   Mon Oct 11 11:43:12 2021 +0800
> 
>     MdeModulePkg/Core/Dxe: Acquire a lock when iterating gHandleList
> 
> where we may end up dereferencing a bogus 'Prot' pointer:
> 
> MdeModulePkg/Core/Dxe/Hand/Handle.c:1198:24:
> error: ‘Prot’ may be used uninitialized [-Werror=maybe-uninitialized]
>  1198 |       *Interface = Prot->Interface;
>       |                    ~~~~^~~~~~~~~~~
> MdeModulePkg/Core/Dxe/Hand/Handle.c:994:24:
> note: ‘Prot’ was declared here
>   994 |   PROTOCOL_INTERFACE  *Prot;
> 
> So I am going to change my mind, and state that I do care about GCC
> non-LTO builds, as we have been introducing bugs into our code that we
> could have spotted if anyone had bothered to test with this toolchain
> config.
> 
> 
> 
>