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

["Ard Biesheuvel" <ardb@kernel.org>]

On Mon, 3 Apr 2023 at 13:39, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Mon, Apr 03, 2023 at 05:33:10AM -0600, Rebecca Cran wrote:
> > On 4/3/23 5:30 AM, Gerd Hoffmann wrote:
> > > I'm wondering what the point in keeping a known-broken toolchain though.
> > > It is apparently unused when nobody noticed the breakage ...
> >
> > I agree. At this point I want to reach a consensus and get this patch series
> > committed, even if that means leaving a known broken toolchain around.
>
> Sure.  That question was meant more for gaoliming who expressed interest
> in keeping it.  gaoliming?
>
> I'd prefer to keep GCC only.  In case we decide to keep both LTO and
> non-LTO variants the GCC + GCCNOLTE naming scheme looks fine to me.
>

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.

Liming, are you aware of any users relying on non-LTO GCC codegen for
any reason?