From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.69583.1680527101993925600 for ; Mon, 03 Apr 2023 06:05:02 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jmPMK0xN; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 31DA461508 for ; Mon, 3 Apr 2023 13:05:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9930EC4339E for ; Mon, 3 Apr 2023 13:05:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680527100; bh=8RkGhQUCYIeh2Ky36QOkm9TwafQbAJPkxSFXL1A4YjU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jmPMK0xNo1/dRMamXVmZzJlr2JKCCbFYhI/47TkBmQ2Tj9r8UTMqEJv9bXC3iWiF7 SATvaOt6Di6ctm8GdCRqRLXX0872wyzKDyIKSQq6BeWpSkvUH4SrgsJN9spHOwyMDV 7U685IAvffO52ynkW90Ly/TPjz2fAlFIoUsdtJbj+bzz/i2jpfxN0WEkpNQ2btZvRL ugvwzADBa+o5e0FAs9BYsEeaiqFemfzo8cR7mpzF8vcgq9Kt8ecr/Yy7LI8LZ0L5qz 2AMWpwk+aY8r3kpL7TyHgls1slnz4xuIwH2DIH/GTSYrOmsS5gNrXIMvcN6byU3uAd jk94tMpqS+hHw== Received: by mail-lj1-f176.google.com with SMTP id x20so30242951ljq.9 for ; Mon, 03 Apr 2023 06:05:00 -0700 (PDT) X-Gm-Message-State: AAQBX9dhINYzWCvqMSQ+ocavixYY0nQXXRXYnw/GbECQE9x7IkOUn5TG 3tj15brZfLsi3fVVxhl0WbnCSHGYT0C47Bo4wM4= X-Google-Smtp-Source: AKy350a1NJxv6oCagm2H0IMCZdcf+Mq+Cabcbii+62tLq5k5GxA6wpT/GqcWsfDnr73e0+GKfkjxbbGA226PUw4tZow= X-Received: by 2002:a2e:9d4d:0:b0:298:b375:acfc with SMTP id y13-20020a2e9d4d000000b00298b375acfcmr10978144ljj.2.1680527098616; Mon, 03 Apr 2023 06:04:58 -0700 (PDT) MIME-Version: 1.0 References: <20230328173111.759017-1-rebecca@bsdio.com> <02fb01d961dc$88d6acd0$9a840670$@byosoft.com.cn> <92a85636-3875-fd4d-06ff-dab9670370a5@bsdio.com> In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 3 Apr 2023 15:04:47 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?B?UmU6IOWbnuWkjTogW2VkazItZGV2ZWxdIFtQQVRDSCB2MiAwMC8xM10gQmFzZVRvb2xzLENyeXB0b1BrZyxNZGVQa2csT3ZtZlBrZzogRGVsZXRlIENMQU5HMzUsQ0xBTkczOCxHQ0M0OCxHQ0M0OSwgcmVuYW1lIEdDQzUgdG8gR0NDLCB1cGRhdGUgQ0xBTkdEV0FSRiwgZGVsZXRlIFZTIDIwMDgtMjAxMywgRUJD?= To: devel@edk2.groups.io, quic_llindhol@quicinc.com Cc: Gerd Hoffmann , rebecca@bsdio.com, Pedro Falcato , gaoliming , Oliver Smith-Denny , Guomin Jiang , Xiaoyu Lu , Jian J Wang , Jiewen Yao , Ard Biesheuvel , Jordan Justen , Bob Feng , Andrew Fish , Michael D Kinney Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 3 Apr 2023 at 14:15, Leif Lindholm wrot= e: > > 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: =E2=80=98XCr0=E2=80=99 may be used uninitialized [-Werror=3Dmayb= e-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 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: =E2=80=98Prot=E2=80=99 may be used uninitialized [-Werror=3Dmaybe-un= initialized] 1198 | *Interface =3D Prot->Interface; | ~~~~^~~~~~~~~~~ MdeModulePkg/Core/Dxe/Hand/Handle.c:994:24: note: =E2=80=98Prot=E2=80=99 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.