UnitTestFrameworkPkg/UnitTestFrameworkPkgHost.dsc.inc | 4 +- IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc | 12 +- OvmfPkg/OvmfPkgX64.dsc | 2 +- CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf | 3 +- CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf | 3 +- CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf | 3 +- CryptoPkg/Library/BaseCryptLib/SecCryptLib.inf | 3 +- CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf | 3 +- CryptoPkg/Library/BaseCryptLib/UnitTestHostBaseCryptLib.inf | 3 +- CryptoPkg/Library/OpensslLib/OpensslLib.inf | 5 +- CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf | 5 +- CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf | 5 +- CryptoPkg/Library/OpensslLib/OpensslLibFull.inf | 5 +- CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf | 5 +- EmulatorPkg/Unix/Host/Host.inf | 6 +- MdePkg/Include/Ia32/ProcessorBind.h | 8 +- MdePkg/Include/X64/ProcessorBind.h | 8 +- OvmfPkg/Library/PlatformInitLib/MemDetect.c | 4 +- OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c | 5 - .azurepipelines/Ubuntu-GCC5.yml | 4 +- .azurepipelines/templates/platform-build-run-steps.yml | 2 +- .azurepipelines/templates/pr-gate-build-job.yml | 2 +- .azurepipelines/templates/pr-gate-steps.yml | 2 +- ArmPlatformPkg/Scripts/Makefile | 2 +- ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 +- ArmVirtPkg/PlatformCI/ReadMe.md | 2 +- BaseTools/Conf/tools_def.template | 2528 ++++---------------- BaseTools/Edk2ToolsBuild.py | 2 +- BaseTools/Plugin/HostBasedUnitTestRunner/HostBasedUnitTestRunner.py | 2 +- BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain.py | 62 +- BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain_plug_in.yaml | 4 +- BaseTools/Scripts/SetVisualStudio.bat | 22 +- BaseTools/Scripts/ShowEnvironment.bat | 44 - BaseTools/get_vsvars.bat | 13 - BaseTools/set_vsprefix_envs.bat | 64 - BaseTools/toolsetup.bat | 24 +- DynamicTablesPkg/Readme.md | 10 +- EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 +- EmulatorPkg/PlatformCI/ReadMe.md | 2 +- EmulatorPkg/Readme.md | 8 +- EmulatorPkg/build.sh | 14 +- OvmfPkg/CloudHv/README | 2 +- OvmfPkg/IntelTdx/README | 4 +- OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 +- OvmfPkg/PlatformCI/ReadMe.md | 2 +- OvmfPkg/README | 4 +- OvmfPkg/build.sh | 12 +- PrmPkg/Readme.md | 6 +- ReadMe.rst | 102 +- UnitTestFrameworkPkg/ReadMe.md | 8 +- edksetup.bat | 6 +- 51 files changed, 592 insertions(+), 2471 deletions(-)
Update the toolchain definitions:
- Delete the CLANG35 and CLANG38 toolchains, and replace CLANG38 with
CLANGDWARF, updating it to support ARM and AARCH64 in addition to X64
and IA32.
- Remove GCC48 and GCC49.
- Remove VS2008, VS2010, VS2012 and VS2013.
- Remove EBC compiler definitions. Full removal of EBC support from the
various packages etc. will be done in a follow-up patch series.
- Remove unused IPHONE_TOOLS and SOURCERY_CYGWIN_TOOLS definitions.
- Remove unused CYGWIN_ definitions.
- Rename GCC5 to GCC.
Personal GitHub PR: https://github.com/tianocore/edk2/pull/4158
GitHub branch: https://github.com/bcran/edk2/tree/clangdwarf
Note: CI will fail due to changes that are needed in the edk2-basetools
and containers repositories.
Changes from v1 to v2:
- Added a commit to delete GCC48 and GCC49, rename GCC5 to GCC and
update the flags for other toolchains to work with the new GCC
definitions.
- Bumped VERSION from 2.00 to 3.00 to inform users that they should
updated their Conf/tools_def.txt.
Rebecca Cran (13):
OvmfPkg: Replace static struct initialization with ZeroMem call
CryptoPkg: Add CLANGDWARF and remove CLANG35 and CLANG38 compiler
flags
BaseTools: Update CLANGDWARF toolchain and remove CLANG35 and CLANG38
BaseTools: Remove VS2008, 2010, 2012 and 2013 toolchain definitions
BaseTools: Remove VS2008-VS2013 remnants
MdePkg: Remove VS2008-VS2013 remnants
edksetup.bat: Remove VS2008-VS2013 remnants
BaseTools: Remove unused IPHONE_TOOLS and SOURCERY_CYGWIN_TOOLS defs
BaseTools: Remove EBC (EFI Byte Code) compiler definitions
OvmfPkg: Use Xcode5 version of CpuExceptionHandlerLib for CLANGDWARF
Delete GCC48 and GCC49 toolchains and rename GCC5 to GCC
BaseTools: Remove unused CYGWIN_ defines from tools_def.txt.template
Bump tools_def.txt VERSION to 3.0
UnitTestFrameworkPkg/UnitTestFrameworkPkgHost.dsc.inc | 4 +-
IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc | 12 +-
OvmfPkg/OvmfPkgX64.dsc | 2 +-
CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf | 3 +-
CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf | 3 +-
CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf | 3 +-
CryptoPkg/Library/BaseCryptLib/SecCryptLib.inf | 3 +-
CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf | 3 +-
CryptoPkg/Library/BaseCryptLib/UnitTestHostBaseCryptLib.inf | 3 +-
CryptoPkg/Library/OpensslLib/OpensslLib.inf | 5 +-
CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf | 5 +-
CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf | 5 +-
CryptoPkg/Library/OpensslLib/OpensslLibFull.inf | 5 +-
CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf | 5 +-
EmulatorPkg/Unix/Host/Host.inf | 6 +-
MdePkg/Include/Ia32/ProcessorBind.h | 8 +-
MdePkg/Include/X64/ProcessorBind.h | 8 +-
OvmfPkg/Library/PlatformInitLib/MemDetect.c | 4 +-
OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c | 5 -
.azurepipelines/Ubuntu-GCC5.yml | 4 +-
.azurepipelines/templates/platform-build-run-steps.yml | 2 +-
.azurepipelines/templates/pr-gate-build-job.yml | 2 +-
.azurepipelines/templates/pr-gate-steps.yml | 2 +-
ArmPlatformPkg/Scripts/Makefile | 2 +-
ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 +-
ArmVirtPkg/PlatformCI/ReadMe.md | 2 +-
BaseTools/Conf/tools_def.template | 2528 ++++----------------
BaseTools/Edk2ToolsBuild.py | 2 +-
BaseTools/Plugin/HostBasedUnitTestRunner/HostBasedUnitTestRunner.py | 2 +-
BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain.py | 62 +-
BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain_plug_in.yaml | 4 +-
BaseTools/Scripts/SetVisualStudio.bat | 22 +-
BaseTools/Scripts/ShowEnvironment.bat | 44 -
BaseTools/get_vsvars.bat | 13 -
BaseTools/set_vsprefix_envs.bat | 64 -
BaseTools/toolsetup.bat | 24 +-
DynamicTablesPkg/Readme.md | 10 +-
EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 +-
EmulatorPkg/PlatformCI/ReadMe.md | 2 +-
EmulatorPkg/Readme.md | 8 +-
EmulatorPkg/build.sh | 14 +-
OvmfPkg/CloudHv/README | 2 +-
OvmfPkg/IntelTdx/README | 4 +-
OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 +-
OvmfPkg/PlatformCI/ReadMe.md | 2 +-
OvmfPkg/README | 4 +-
OvmfPkg/build.sh | 12 +-
PrmPkg/Readme.md | 6 +-
ReadMe.rst | 102 +-
UnitTestFrameworkPkg/ReadMe.md | 8 +-
edksetup.bat | 6 +-
51 files changed, 592 insertions(+), 2471 deletions(-)
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102039): https://edk2.groups.io/g/devel/message/102039
Mute This Topic: https://groups.io/mt/97910990/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
On Tue, 28 Mar 2023 at 19:31, Rebecca Cran <rebecca@bsdio.com> wrote: > > Update the toolchain definitions: > > - Delete the CLANG35 and CLANG38 toolchains, and replace CLANG38 with > CLANGDWARF, updating it to support ARM and AARCH64 in addition to X64 > and IA32. > > - Remove GCC48 and GCC49. > > - Remove VS2008, VS2010, VS2012 and VS2013. > > - Remove EBC compiler definitions. Full removal of EBC support from the > various packages etc. will be done in a follow-up patch series. > > - Remove unused IPHONE_TOOLS and SOURCERY_CYGWIN_TOOLS definitions. > > - Remove unused CYGWIN_ definitions. > > - Rename GCC5 to GCC. > > Personal GitHub PR: https://github.com/tianocore/edk2/pull/4158 > GitHub branch: https://github.com/bcran/edk2/tree/clangdwarf > > Note: CI will fail due to changes that are needed in the edk2-basetools > and containers repositories. > > Changes from v1 to v2: > > - Added a commit to delete GCC48 and GCC49, rename GCC5 to GCC and > update the flags for other toolchains to work with the new GCC > definitions. > > - Bumped VERSION from 2.00 to 3.00 to inform users that they should > updated their Conf/tools_def.txt. > > Rebecca Cran (13): > OvmfPkg: Replace static struct initialization with ZeroMem call > CryptoPkg: Add CLANGDWARF and remove CLANG35 and CLANG38 compiler > flags > BaseTools: Update CLANGDWARF toolchain and remove CLANG35 and CLANG38 > BaseTools: Remove VS2008, 2010, 2012 and 2013 toolchain definitions > BaseTools: Remove VS2008-VS2013 remnants > MdePkg: Remove VS2008-VS2013 remnants > edksetup.bat: Remove VS2008-VS2013 remnants > BaseTools: Remove unused IPHONE_TOOLS and SOURCERY_CYGWIN_TOOLS defs > BaseTools: Remove EBC (EFI Byte Code) compiler definitions > OvmfPkg: Use Xcode5 version of CpuExceptionHandlerLib for CLANGDWARF > Delete GCC48 and GCC49 toolchains and rename GCC5 to GCC > BaseTools: Remove unused CYGWIN_ defines from tools_def.txt.template > Bump tools_def.txt VERSION to 3.0 > I've cherry-picked the two OvmfPkg/ patches from this series, so no need to resend those. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102121): https://edk2.groups.io/g/devel/message/102121 Mute This Topic: https://groups.io/mt/97910990/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Hi Rebecca, Thanks for respining this. On Tue, 28 Mar 2023 at 19:31, Rebecca Cran <rebecca@bsdio.com> wrote: > > Update the toolchain definitions: > > - Delete the CLANG35 and CLANG38 toolchains, and replace CLANG38 with > CLANGDWARF, updating it to support ARM and AARCH64 in addition to X64 > and IA32. > As I have indicated before, I am strongly in favor of these changes. However, using LLD with X86 and GNU ld with ARM is not what I would like to see here: not only is it a bad idea for a single toolchain definition to deviate in this manner between architectures, I also think that having the ability to use LLD for ARM would be nice in itself, as it removes the need for cross toolchains entirely, lowering the bar for contributors to ensure that their changes do not regress other architectures. And there are some differences related to BTI that could be interesting as well. > - Remove GCC48 and GCC49. > > - Remove VS2008, VS2010, VS2012 and VS2013. > > - Remove EBC compiler definitions. Full removal of EBC support from the > various packages etc. will be done in a follow-up patch series. > > - Remove unused IPHONE_TOOLS and SOURCERY_CYGWIN_TOOLS definitions. > > - Remove unused CYGWIN_ definitions. > > - Rename GCC5 to GCC. > > Personal GitHub PR: https://github.com/tianocore/edk2/pull/4158 > GitHub branch: https://github.com/bcran/edk2/tree/clangdwarf > > Note: CI will fail due to changes that are needed in the edk2-basetools > and containers repositories. > > Changes from v1 to v2: > > - Added a commit to delete GCC48 and GCC49, rename GCC5 to GCC and > update the flags for other toolchains to work with the new GCC > definitions. > > - Bumped VERSION from 2.00 to 3.00 to inform users that they should > updated their Conf/tools_def.txt. > > Rebecca Cran (13): > OvmfPkg: Replace static struct initialization with ZeroMem call > CryptoPkg: Add CLANGDWARF and remove CLANG35 and CLANG38 compiler > flags > BaseTools: Update CLANGDWARF toolchain and remove CLANG35 and CLANG38 > BaseTools: Remove VS2008, 2010, 2012 and 2013 toolchain definitions > BaseTools: Remove VS2008-VS2013 remnants > MdePkg: Remove VS2008-VS2013 remnants > edksetup.bat: Remove VS2008-VS2013 remnants > BaseTools: Remove unused IPHONE_TOOLS and SOURCERY_CYGWIN_TOOLS defs > BaseTools: Remove EBC (EFI Byte Code) compiler definitions > OvmfPkg: Use Xcode5 version of CpuExceptionHandlerLib for CLANGDWARF > Delete GCC48 and GCC49 toolchains and rename GCC5 to GCC > BaseTools: Remove unused CYGWIN_ defines from tools_def.txt.template > Bump tools_def.txt VERSION to 3.0 > > UnitTestFrameworkPkg/UnitTestFrameworkPkgHost.dsc.inc | 4 +- > IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc | 12 +- > OvmfPkg/OvmfPkgX64.dsc | 2 +- > CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf | 3 +- > CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf | 3 +- > CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf | 3 +- > CryptoPkg/Library/BaseCryptLib/SecCryptLib.inf | 3 +- > CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf | 3 +- > CryptoPkg/Library/BaseCryptLib/UnitTestHostBaseCryptLib.inf | 3 +- > CryptoPkg/Library/OpensslLib/OpensslLib.inf | 5 +- > CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf | 5 +- > CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf | 5 +- > CryptoPkg/Library/OpensslLib/OpensslLibFull.inf | 5 +- > CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf | 5 +- > EmulatorPkg/Unix/Host/Host.inf | 6 +- > MdePkg/Include/Ia32/ProcessorBind.h | 8 +- > MdePkg/Include/X64/ProcessorBind.h | 8 +- > OvmfPkg/Library/PlatformInitLib/MemDetect.c | 4 +- > OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c | 5 - > .azurepipelines/Ubuntu-GCC5.yml | 4 +- > .azurepipelines/templates/platform-build-run-steps.yml | 2 +- > .azurepipelines/templates/pr-gate-build-job.yml | 2 +- > .azurepipelines/templates/pr-gate-steps.yml | 2 +- > ArmPlatformPkg/Scripts/Makefile | 2 +- > ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 +- > ArmVirtPkg/PlatformCI/ReadMe.md | 2 +- > BaseTools/Conf/tools_def.template | 2528 ++++---------------- > BaseTools/Edk2ToolsBuild.py | 2 +- > BaseTools/Plugin/HostBasedUnitTestRunner/HostBasedUnitTestRunner.py | 2 +- > BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain.py | 62 +- > BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain_plug_in.yaml | 4 +- > BaseTools/Scripts/SetVisualStudio.bat | 22 +- > BaseTools/Scripts/ShowEnvironment.bat | 44 - > BaseTools/get_vsvars.bat | 13 - > BaseTools/set_vsprefix_envs.bat | 64 - > BaseTools/toolsetup.bat | 24 +- > DynamicTablesPkg/Readme.md | 10 +- > EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 +- > EmulatorPkg/PlatformCI/ReadMe.md | 2 +- > EmulatorPkg/Readme.md | 8 +- > EmulatorPkg/build.sh | 14 +- > OvmfPkg/CloudHv/README | 2 +- > OvmfPkg/IntelTdx/README | 4 +- > OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 +- > OvmfPkg/PlatformCI/ReadMe.md | 2 +- > OvmfPkg/README | 4 +- > OvmfPkg/build.sh | 12 +- > PrmPkg/Readme.md | 6 +- > ReadMe.rst | 102 +- > UnitTestFrameworkPkg/ReadMe.md | 8 +- > edksetup.bat | 6 +- > 51 files changed, 592 insertions(+), 2471 deletions(-) > > -- > 2.34.1 > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102053): https://edk2.groups.io/g/devel/message/102053 Mute This Topic: https://groups.io/mt/97910990/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 3/28/23 11:57 AM, Ard Biesheuvel wrote: > > As I have indicated before, I am strongly in favor of these changes. > However, using LLD with X86 and GNU ld with ARM is not what I would > like to see here: not only is it a bad idea for a single toolchain > definition to deviate in this manner between architectures, I also > think that having the ability to use LLD for ARM would be nice in > itself, as it removes the need for cross toolchains entirely, lowering > the bar for contributors to ensure that their changes do not regress > other architectures. And there are some differences related to BTI > that could be interesting as well. I agree, it's not ideal. My knowledge of linker issues is relatively limited at the moment, which is why I decided not to use LLD when I saw it was failing. I can spend some time learning about it and send out a v3 with LLD enabled for ARM. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102054): https://edk2.groups.io/g/devel/message/102054 Mute This Topic: https://groups.io/mt/97910990/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Tue, 28 Mar 2023 at 20:01, Rebecca Cran <rebecca@bsdio.com> wrote: > > On 3/28/23 11:57 AM, Ard Biesheuvel wrote: > > > > > As I have indicated before, I am strongly in favor of these changes. > > However, using LLD with X86 and GNU ld with ARM is not what I would > > like to see here: not only is it a bad idea for a single toolchain > > definition to deviate in this manner between architectures, I also > > think that having the ability to use LLD for ARM would be nice in > > itself, as it removes the need for cross toolchains entirely, lowering > > the bar for contributors to ensure that their changes do not regress > > other architectures. And there are some differences related to BTI > > that could be interesting as well. > > I agree, it's not ideal. My knowledge of linker issues is relatively > limited at the moment, which is why I decided not to use LLD when I saw > it was failing. > > I can spend some time learning about it and send out a v3 with LLD > enabled for ARM. > Happy to help What kind of errors are you seeing after adding -Wl,--no-pie,--no-relax ? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102058): https://edk2.groups.io/g/devel/message/102058 Mute This Topic: https://groups.io/mt/97910990/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 3/28/23 12:12 PM, Ard Biesheuvel wrote: > What kind of errors are you seeing after adding -Wl,--no-pie,--no-relax ? I realized I didn't really try it after I thought you had said it was causing corruption. After adding those flags I was able to verify (via "strace --trace=process -f") that lld is indeed getting invoked, and that the resulting binaries run fine using qemu-system-arm and qemu-system-aarch64. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102111): https://edk2.groups.io/g/devel/message/102111 Mute This Topic: https://groups.io/mt/97910990/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, 29 Mar 2023 at 12:22, Rebecca Cran <rebecca@bsdio.com> wrote: > > On 3/28/23 12:12 PM, Ard Biesheuvel wrote: > > What kind of errors are you seeing after adding -Wl,--no-pie,--no-relax ? > > I realized I didn't really try it after I thought you had said it was > causing corruption. > > After adding those flags I was able to verify (via "strace > --trace=process -f") that lld is indeed getting invoked, and that the > resulting binaries run fine using qemu-system-arm and qemu-system-aarch64. > Excellent, so let's go with that. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102113): https://edk2.groups.io/g/devel/message/102113 Mute This Topic: https://groups.io/mt/97910990/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Rebecca: > -----邮件原件----- > 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Rebecca Cran > 发送时间: 2023年3月29日 1:31 > 收件人: devel@edk2.groups.io; Oliver Smith-Denny <osd@smith-denny.com>; > Guomin Jiang <guomin.jiang@intel.com>; Xiaoyu Lu <xiaoyu1.lu@intel.com>; > Jian J Wang <jian.j.wang@intel.com>; Jiewen Yao <jiewen.yao@intel.com>; > Ard Biesheuvel <ardb+tianocore@kernel.org>; Jordan Justen > <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Bob Feng > <bob.c.feng@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>; Andrew > Fish <afish@apple.com>; Leif Lindholm <quic_llindhol@quicinc.com>; > Michael D Kinney <michael.d.kinney@intel.com> > 抄送: Rebecca Cran <rebecca@bsdio.com> > 主题: [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 > > Update the toolchain definitions: > > - Delete the CLANG35 and CLANG38 toolchains, and replace CLANG38 with > CLANGDWARF, updating it to support ARM and AARCH64 in addition to X64 > and IA32. > > - Remove GCC48 and GCC49. GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC tool chain with LTO enable option. They have the different usage. I suggest to keep GCC49 and GCC5 both, and also keep their name as is. Thanks Liming > > - Remove VS2008, VS2010, VS2012 and VS2013. > > - Remove EBC compiler definitions. Full removal of EBC support from the > various packages etc. will be done in a follow-up patch series. > > - Remove unused IPHONE_TOOLS and SOURCERY_CYGWIN_TOOLS > definitions. > > - Remove unused CYGWIN_ definitions. > > - Rename GCC5 to GCC. > > Personal GitHub PR: https://github.com/tianocore/edk2/pull/4158 > GitHub branch: https://github.com/bcran/edk2/tree/clangdwarf > > Note: CI will fail due to changes that are needed in the edk2-basetools > and containers repositories. > > Changes from v1 to v2: > > - Added a commit to delete GCC48 and GCC49, rename GCC5 to GCC and > update the flags for other toolchains to work with the new GCC > definitions. > > - Bumped VERSION from 2.00 to 3.00 to inform users that they should > updated their Conf/tools_def.txt. > > Rebecca Cran (13): > OvmfPkg: Replace static struct initialization with ZeroMem call > CryptoPkg: Add CLANGDWARF and remove CLANG35 and CLANG38 > compiler > flags > BaseTools: Update CLANGDWARF toolchain and remove CLANG35 and > CLANG38 > BaseTools: Remove VS2008, 2010, 2012 and 2013 toolchain definitions > BaseTools: Remove VS2008-VS2013 remnants > MdePkg: Remove VS2008-VS2013 remnants > edksetup.bat: Remove VS2008-VS2013 remnants > BaseTools: Remove unused IPHONE_TOOLS and > SOURCERY_CYGWIN_TOOLS defs > BaseTools: Remove EBC (EFI Byte Code) compiler definitions > OvmfPkg: Use Xcode5 version of CpuExceptionHandlerLib for > CLANGDWARF > Delete GCC48 and GCC49 toolchains and rename GCC5 to GCC > BaseTools: Remove unused CYGWIN_ defines from tools_def.txt.template > Bump tools_def.txt VERSION to 3.0 > > UnitTestFrameworkPkg/UnitTestFrameworkPkgHost.dsc.inc > | 4 +- > IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc > | 12 +- > OvmfPkg/OvmfPkgX64.dsc > | 2 +- > CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf > | 3 +- > CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf | > 3 +- > CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf > | 3 +- > CryptoPkg/Library/BaseCryptLib/SecCryptLib.inf > | 3 +- > CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > | 3 +- > CryptoPkg/Library/BaseCryptLib/UnitTestHostBaseCryptLib.inf | > 3 +- > CryptoPkg/Library/OpensslLib/OpensslLib.inf > | 5 +- > CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf | > 5 +- > CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf | > 5 +- > CryptoPkg/Library/OpensslLib/OpensslLibFull.inf | > 5 +- > CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf | > 5 +- > EmulatorPkg/Unix/Host/Host.inf > | 6 +- > MdePkg/Include/Ia32/ProcessorBind.h > | 8 +- > MdePkg/Include/X64/ProcessorBind.h > | 8 +- > OvmfPkg/Library/PlatformInitLib/MemDetect.c > | 4 +- > OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c > | 5 - > .azurepipelines/Ubuntu-GCC5.yml > | 4 +- > .azurepipelines/templates/platform-build-run-steps.yml | > 2 +- > .azurepipelines/templates/pr-gate-build-job.yml | > 2 +- > .azurepipelines/templates/pr-gate-steps.yml > | 2 +- > ArmPlatformPkg/Scripts/Makefile > | 2 +- > ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml > | 4 +- > ArmVirtPkg/PlatformCI/ReadMe.md > | 2 +- > BaseTools/Conf/tools_def.template > | 2528 ++++---------------- > BaseTools/Edk2ToolsBuild.py > | 2 +- > BaseTools/Plugin/HostBasedUnitTestRunner/HostBasedUnitTestRunner.py | > 2 +- > BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain.py | > 62 +- > BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain_plug_in.yaml | > 4 +- > BaseTools/Scripts/SetVisualStudio.bat > | 22 +- > BaseTools/Scripts/ShowEnvironment.bat > | 44 - > BaseTools/get_vsvars.bat > | 13 - > BaseTools/set_vsprefix_envs.bat > | 64 - > BaseTools/toolsetup.bat > | 24 +- > DynamicTablesPkg/Readme.md > | 10 +- > EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml > | 4 +- > EmulatorPkg/PlatformCI/ReadMe.md > | 2 +- > EmulatorPkg/Readme.md > | 8 +- > EmulatorPkg/build.sh > | 14 +- > OvmfPkg/CloudHv/README > | 2 +- > OvmfPkg/IntelTdx/README > | 4 +- > OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml > | 4 +- > OvmfPkg/PlatformCI/ReadMe.md > | 2 +- > OvmfPkg/README > | 4 +- > OvmfPkg/build.sh > | 12 +- > PrmPkg/Readme.md > | 6 +- > ReadMe.rst > | 102 +- > UnitTestFrameworkPkg/ReadMe.md > | 8 +- > edksetup.bat > | 6 +- > 51 files changed, 592 insertions(+), 2471 deletions(-) > > -- > 2.34.1 > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102076): https://edk2.groups.io/g/devel/message/102076 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, 29 Mar 2023 at 03:20, gaoliming via groups.io <gaoliming=byosoft.com.cn@groups.io> wrote: > > Rebecca: > > > > -----邮件原件----- > > 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Rebecca Cran > > 发送时间: 2023年3月29日 1:31 > > 收件人: devel@edk2.groups.io; Oliver Smith-Denny <osd@smith-denny.com>; > > Guomin Jiang <guomin.jiang@intel.com>; Xiaoyu Lu <xiaoyu1.lu@intel.com>; > > Jian J Wang <jian.j.wang@intel.com>; Jiewen Yao <jiewen.yao@intel.com>; > > Ard Biesheuvel <ardb+tianocore@kernel.org>; Jordan Justen > > <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Bob Feng > > <bob.c.feng@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>; Andrew > > Fish <afish@apple.com>; Leif Lindholm <quic_llindhol@quicinc.com>; > > Michael D Kinney <michael.d.kinney@intel.com> > > 抄送: Rebecca Cran <rebecca@bsdio.com> > > 主题: [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 > > > > Update the toolchain definitions: > > > > - Delete the CLANG35 and CLANG38 toolchains, and replace CLANG38 with > > CLANGDWARF, updating it to support ARM and AARCH64 in addition to X64 > > and IA32. > > > > - Remove GCC48 and GCC49. > > GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC tool chain with LTO enable option. > > They have the different usage. I suggest to keep GCC49 and GCC5 both, and also keep their name as is. > Could we perhaps do GCC49 -> GCC GCC5 -> GCCLTO ? As with CLANG35/38, the GCCx names have become rather obsolete, so I'd prefer to have a set of more generic names, and a sliding window of supported versions that can be documented in tools_def.template (and updated at times) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102105): https://edk2.groups.io/g/devel/message/102105 Mute This Topic: https://groups.io/mt/97923603/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, Mar 29, 2023 at 09:39:56 +0200, Ard Biesheuvel wrote:
> > > - Remove GCC48 and GCC49.
> >
> > GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC tool chain with LTO enable option.
> >
> > They have the different usage. I suggest to keep GCC49 and GCC5 both, and also keep their name as is.
> >
>
> Could we perhaps do
>
> GCC49 -> GCC
> GCC5 -> GCCLTO
Might I suggest the inverse?
GCC49 -> GCCNOLTO
GCC5 -> GCC
I feel disabling LTO should be seen as the nonstandard approach.
Regardless, we (including me) *should* have changed those names as
soon as we realised we didn't need a GCC51, and the misleading naming
still frequently causes confusion. So I don't think keeping the
current names should be considered an option.
> ?
>
> As with CLANG35/38, the GCCx names have become rather obsolete, so I'd
> prefer to have a set of more generic names, and a sliding window of
> supported versions that can be documented in tools_def.template (and
> updated at times)
Agreed. And *if* we find a need in the future to add a new archived
range, we can add that then.
/
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102116): https://edk2.groups.io/g/devel/message/102116
Mute This Topic: https://groups.io/mt/97923603/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
On Wed, 29 Mar 2023 at 13:28, Leif Lindholm <quic_llindhol@quicinc.com> wrote: > > On Wed, Mar 29, 2023 at 09:39:56 +0200, Ard Biesheuvel wrote: > > > > - Remove GCC48 and GCC49. > > > > > > GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC tool chain with LTO enable option. > > > > > > They have the different usage. I suggest to keep GCC49 and GCC5 both, and also keep their name as is. > > > > > > > Could we perhaps do > > > > GCC49 -> GCC > > GCC5 -> GCCLTO > > Might I suggest the inverse? > > GCC49 -> GCCNOLTO > GCC5 -> GCC > > I feel disabling LTO should be seen as the nonstandard approach. > That works for me as well. > Regardless, we (including me) *should* have changed those names as > soon as we realised we didn't need a GCC51, and the misleading naming > still frequently causes confusion. So I don't think keeping the > current names should be considered an option. > Agreed. > > ? > > > > As with CLANG35/38, the GCCx names have become rather obsolete, so I'd > > prefer to have a set of more generic names, and a sliding window of > > supported versions that can be documented in tools_def.template (and > > updated at times) > > Agreed. And *if* we find a need in the future to add a new archived > range, we can add that then. > Of course. But with the stable tags, I doubt whether this will be necessary. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102117): https://edk2.groups.io/g/devel/message/102117 Mute This Topic: https://groups.io/mt/97923603/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 3/29/23 1:39 AM, Ard Biesheuvel wrote: > Could we perhaps do > > GCC49 -> GCC > GCC5 -> GCCLTO > > ? > > As with CLANG35/38, the GCCx names have become rather obsolete, so I'd > prefer to have a set of more generic names, and a sliding window of > supported versions that can be documented in tools_def.template (and > updated at times) We need a minimum of GCC 6 to run CI because UnitTestFrameworkPkg/Library/GoogleTestLib uses nullptr that GCC 5 doesn't support, so the GCC5 name is wrong anyway. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102110): https://edk2.groups.io/g/devel/message/102110 Mute This Topic: https://groups.io/mt/97923603/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 3/28/23 7:19 PM, gaoliming wrote: > GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC tool chain with LTO enable option. > > They have the different usage. I suggest to keep GCC49 and GCC5 both, and also keep their name as is. Is anything still _using_ GCC49 though? Since I strongly suspect nobody is using gcc 4.9, I'll rename it to GCCNOLTO. When I try and build OVMF with it, I get the following error: /UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c: In function ‘InternalSetPageState’: /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:166:37: error: ‘Cmd’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 166 | Info->Entry[i].CurrentPage = 0; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:32:10: note: ‘Cmd’ was declared here 32 | UINTN Cmd; | ^~~ rm -f /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib "ar" cr /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib @/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/object_files.lst cc1: all warnings being treated as errors make: *** [GNUmakefile:304: /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib/OUTPUT/X64/SnpPageStateChangeInternal.obj] Error 1 build.py... : error 7000: Failed to execute command make tbuild [/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib] build.py... : error F002: Failed to build module /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf [X64, GCC49, RELEASE] - Failed - Build end time: 09:38:34, Apr.02 2023 Build total time: 00:00:14 -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102361): https://edk2.groups.io/g/devel/message/102361 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Sun, Apr 2, 2023 at 4:41 PM Rebecca Cran <rebecca@bsdio.com> wrote: > > On 3/28/23 7:19 PM, gaoliming wrote: > > > GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC tool chain with LTO enable option. > > > > They have the different usage. I suggest to keep GCC49 and GCC5 both, and also keep their name as is. > > Is anything still _using_ GCC49 though? Since I strongly suspect nobody > is using gcc 4.9, I'll rename it to GCCNOLTO. As expressed off-list on UEFI talkbox, I like GCCNOLTO, but I would rather keep GCC5 as GCC5, for the next future iteration of "lets bump a new toolchain because we need feature X". > > When I try and build OVMF with it, I get the following error: > > > /UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c: > In function ‘InternalSetPageState’: > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:166:37: > error: ‘Cmd’ may be used uninitialized in this function > [-Werror=maybe-uninitialized] > 166 | Info->Entry[i].CurrentPage = 0; > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:32:10: > note: ‘Cmd’ was declared here > 32 | UINTN Cmd; > | ^~~ > rm -f > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > "ar" cr > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > @/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/object_files.lst > cc1: all warnings being treated as errors > make: *** [GNUmakefile:304: > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib/OUTPUT/X64/SnpPageStateChangeInternal.obj] > Error 1 This is unsurprising, plenty of NOLTO build breakage. Since no one seems to use this, could we think about axing this or? Just seems silly to have an extra toolchain (with extra cognitive overhead for anyone looking at tools_def) for s/-flto//g -- Pedro -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102365): https://edk2.groups.io/g/devel/message/102365 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 4/2/23 12:38 PM, Pedro Falcato wrote: > As expressed off-list on UEFI talkbox, I like GCCNOLTO, but I would > rather keep GCC5 as GCC5, for the next future iteration of "lets bump > a new toolchain because we need feature X". Given we've gone from GCC 5 through 12 with no new toolchains, I'd prefer to just have GCC. > This is unsurprising, plenty of NOLTO build breakage. Since no one > seems to use this, could we think about axing this or? > > Just seems silly to have an extra toolchain (with extra cognitive > overhead for anyone looking at tools_def) for s/-flto//g Since Liming wants to keep it, let's make all the other changes (deleting VS 2008-2013, CLANG35, CLANG38 etc.) and keep GCCNOLTO and GCC for now. If nobody fixes the problems with GCCNOLTO, maybe we can revisit dropping it in a few months? -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102366): https://edk2.groups.io/g/devel/message/102366 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Rebecca: There are more discussion on GCC49 tool chain. So, I think it is the safe way to keep GCC49 and GCC5 now. We can make the changes for other tool chains first. Thanks Liming > -----邮件原件----- > 发件人: Rebecca Cran <rebecca@bsdio.com> > 发送时间: 2023年4月3日 5:51 > 收件人: Pedro Falcato <pedro.falcato@gmail.com>; devel@edk2.groups.io > 抄送: gaoliming <gaoliming@byosoft.com.cn>; Oliver Smith-Denny > <osd@smith-denny.com>; Guomin Jiang <guomin.jiang@intel.com>; Xiaoyu > Lu <xiaoyu1.lu@intel.com>; Jian J Wang <jian.j.wang@intel.com>; Jiewen Yao > <jiewen.yao@intel.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; > Jordan Justen <jordan.l.justen@intel.com>; Gerd Hoffmann > <kraxel@redhat.com>; Bob Feng <bob.c.feng@intel.com>; Andrew Fish > <afish@apple.com>; Leif Lindholm <quic_llindhol@quicinc.com>; Michael D > Kinney <michael.d.kinney@intel.com> > 主题: 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 4/2/23 12:38 PM, Pedro Falcato wrote: > > As expressed off-list on UEFI talkbox, I like GCCNOLTO, but I would > > rather keep GCC5 as GCC5, for the next future iteration of "lets bump > > a new toolchain because we need feature X". > > Given we've gone from GCC 5 through 12 with no new toolchains, I'd > prefer to just have GCC. > > > This is unsurprising, plenty of NOLTO build breakage. Since no one > > seems to use this, could we think about axing this or? > > > > Just seems silly to have an extra toolchain (with extra cognitive > > overhead for anyone looking at tools_def) for s/-flto//g > > Since Liming wants to keep it, let's make all the other changes > (deleting VS 2008-2013, CLANG35, CLANG38 etc.) and keep GCCNOLTO and > GCC > for now. If nobody fixes the problems with GCCNOLTO, maybe we can > revisit dropping it in a few months? > > > -- > > Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102455): https://edk2.groups.io/g/devel/message/102455 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Okay. I'll rework the patch series to only delete GCC48 and keep GCC49 and GCC5. -- Rebecca Cran On 4/3/23 7:31 PM, gaoliming wrote: > Rebecca: > There are more discussion on GCC49 tool chain. So, I think it is the safe way to keep GCC49 and GCC5 now. We can make the changes for other tool chains first. > > Thanks > Liming >> -----邮件原件----- >> 发件人: Rebecca Cran <rebecca@bsdio.com> >> 发送时间: 2023年4月3日 5:51 >> 收件人: Pedro Falcato <pedro.falcato@gmail.com>; devel@edk2.groups.io >> 抄送: gaoliming <gaoliming@byosoft.com.cn>; Oliver Smith-Denny >> <osd@smith-denny.com>; Guomin Jiang <guomin.jiang@intel.com>; Xiaoyu >> Lu <xiaoyu1.lu@intel.com>; Jian J Wang <jian.j.wang@intel.com>; Jiewen Yao >> <jiewen.yao@intel.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; >> Jordan Justen <jordan.l.justen@intel.com>; Gerd Hoffmann >> <kraxel@redhat.com>; Bob Feng <bob.c.feng@intel.com>; Andrew Fish >> <afish@apple.com>; Leif Lindholm <quic_llindhol@quicinc.com>; Michael D >> Kinney <michael.d.kinney@intel.com> >> 主题: 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 4/2/23 12:38 PM, Pedro Falcato wrote: >>> As expressed off-list on UEFI talkbox, I like GCCNOLTO, but I would >>> rather keep GCC5 as GCC5, for the next future iteration of "lets bump >>> a new toolchain because we need feature X". >> Given we've gone from GCC 5 through 12 with no new toolchains, I'd >> prefer to just have GCC. >> >>> This is unsurprising, plenty of NOLTO build breakage. Since no one >>> seems to use this, could we think about axing this or? >>> >>> Just seems silly to have an extra toolchain (with extra cognitive >>> overhead for anyone looking at tools_def) for s/-flto//g >> Since Liming wants to keep it, let's make all the other changes >> (deleting VS 2008-2013, CLANG35, CLANG38 etc.) and keep GCCNOLTO and >> GCC >> for now. If nobody fixes the problems with GCCNOLTO, maybe we can >> revisit dropping it in a few months? >> >> >> -- >> >> Rebecca Cran > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102496): https://edk2.groups.io/g/devel/message/102496 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Tue, Apr 4, 2023 at 4:49 PM Rebecca Cran <rebecca@bsdio.com> wrote: > > Okay. I'll rework the patch series to only delete GCC48 and keep GCC49 > and GCC5. Please rename them? There's no point in keeping their current names anyway. I guarantee you that most people are not really able to guess GCC49 to be the "non-LTO" flavor. And IMO Ard has already proved the value in non-LTO builds anyway, so yeah. GCC and GCCNOLTO please. -- Pedro -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102497): https://edk2.groups.io/g/devel/message/102497 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Tue, Apr 04, 2023 at 16:57:18 +0100, Pedro Falcato wrote:
> On Tue, Apr 4, 2023 at 4:49 PM Rebecca Cran <rebecca@bsdio.com> wrote:
> >
> > Okay. I'll rework the patch series to only delete GCC48 and keep GCC49
> > and GCC5.
>
> Please rename them? There's no point in keeping their current names
> anyway. I guarantee you that most people are not really able to guess
> GCC49 to be the "non-LTO" flavor.
>
> And IMO Ard has already proved the value in non-LTO builds anyway, so
> yeah. GCC and GCCNOLTO please.
Agreed. I don't think there are any outstanding items that need
resolving.
I'd be very happy to stop hearing "you need GCC 5 in order to build
edk2" misunderstandings.
/
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102501): https://edk2.groups.io/g/devel/message/102501
Mute This Topic: https://groups.io/mt/98051589/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
On 4/4/23 10:32 AM, Leif Lindholm wrote: > On Tue, Apr 04, 2023 at 16:57:18 +0100, Pedro Falcato wrote: >> On Tue, Apr 4, 2023 at 4:49 PM Rebecca Cran <rebecca@bsdio.com> wrote: >>> Okay. I'll rework the patch series to only delete GCC48 and keep GCC49 >>> and GCC5. >> Please rename them? There's no point in keeping their current names >> anyway. I guarantee you that most people are not really able to guess >> GCC49 to be the "non-LTO" flavor. >> >> And IMO Ard has already proved the value in non-LTO builds anyway, so >> yeah. GCC and GCCNOLTO please. > Agreed. I don't think there are any outstanding items that need > resolving. > > I'd be very happy to stop hearing "you need GCC 5 in order to build > edk2" misunderstandings. Thanks! As a new co-maintainer I was trying to be diplomatic, but I really don't see any reason to keep the existing names. I'll send out a v3 patch series with all the fixes I and others have identified. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102510): https://edk2.groups.io/g/devel/message/102510 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Changing the toolchain tag name from GCC5 to GCC will break EDK II CI and likely 100's of downstream developer/CI scripts. Can we keep GCC5 and add GCC that is identical to GCC5? Mike > -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran > Sent: Tuesday, April 4, 2023 10:01 AM > To: Leif Lindholm <quic_llindhol@quicinc.com>; devel@edk2.groups.io; pedro.falcato@gmail.com > Cc: 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>; Gerd > Hoffmann <kraxel@redhat.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 4/4/23 10:32 AM, Leif Lindholm wrote: > > On Tue, Apr 04, 2023 at 16:57:18 +0100, Pedro Falcato wrote: > >> On Tue, Apr 4, 2023 at 4:49 PM Rebecca Cran <rebecca@bsdio.com> wrote: > >>> Okay. I'll rework the patch series to only delete GCC48 and keep GCC49 > >>> and GCC5. > >> Please rename them? There's no point in keeping their current names > >> anyway. I guarantee you that most people are not really able to guess > >> GCC49 to be the "non-LTO" flavor. > >> > >> And IMO Ard has already proved the value in non-LTO builds anyway, so > >> yeah. GCC and GCCNOLTO please. > > Agreed. I don't think there are any outstanding items that need > > resolving. > > > > I'd be very happy to stop hearing "you need GCC 5 in order to build > > edk2" misunderstandings. > > Thanks! As a new co-maintainer I was trying to be diplomatic, but I > really don't see any reason to keep the existing names. > > I'll send out a v3 patch series with all the fixes I and others have > identified. > > > -- > Rebecca Cran > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102512): https://edk2.groups.io/g/devel/message/102512 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
I've already added changes to the patch series to fix EDK2 CI to use the new name. Fortunately there aren't many places that need updated. Downstream scripts should be trivial to change: just do a find/replace for GCC5. -- Rebecca Cran On 4/4/23 11:45 AM, Kinney, Michael D wrote: > Changing the toolchain tag name from GCC5 to GCC will break > EDK II CI and likely 100's of downstream developer/CI scripts. > > Can we keep GCC5 and add GCC that is identical to GCC5? > > Mike > >> -----Original Message----- >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran >> Sent: Tuesday, April 4, 2023 10:01 AM >> To: Leif Lindholm <quic_llindhol@quicinc.com>; devel@edk2.groups.io; pedro.falcato@gmail.com >> Cc: 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>; Gerd >> Hoffmann <kraxel@redhat.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 4/4/23 10:32 AM, Leif Lindholm wrote: >>> On Tue, Apr 04, 2023 at 16:57:18 +0100, Pedro Falcato wrote: >>>> On Tue, Apr 4, 2023 at 4:49 PM Rebecca Cran <rebecca@bsdio.com> wrote: >>>>> Okay. I'll rework the patch series to only delete GCC48 and keep GCC49 >>>>> and GCC5. >>>> Please rename them? There's no point in keeping their current names >>>> anyway. I guarantee you that most people are not really able to guess >>>> GCC49 to be the "non-LTO" flavor. >>>> >>>> And IMO Ard has already proved the value in non-LTO builds anyway, so >>>> yeah. GCC and GCCNOLTO please. >>> Agreed. I don't think there are any outstanding items that need >>> resolving. >>> >>> I'd be very happy to stop hearing "you need GCC 5 in order to build >>> edk2" misunderstandings. >> Thanks! As a new co-maintainer I was trying to be diplomatic, but I >> really don't see any reason to keep the existing names. >> >> I'll send out a v3 patch series with all the fixes I and others have >> identified. >> >> >> -- >> Rebecca Cran >> >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102513): https://edk2.groups.io/g/devel/message/102513 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
I see value in adding a new name. I see no value in a non-backwards compatible change to delete/rename a fully supported one. Mike > -----Original Message----- > From: Rebecca Cran <rebecca@bsdio.com> > Sent: Tuesday, April 4, 2023 10:49 AM > To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Leif Lindholm <quic_llindhol@quicinc.com>; > pedro.falcato@gmail.com > Cc: 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>; Gerd > Hoffmann <kraxel@redhat.com>; Feng, Bob C <bob.c.feng@intel.com>; Andrew Fish <afish@apple.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 > > I've already added changes to the patch series to fix EDK2 CI to use the > new name. Fortunately there aren't many places that need updated. > > Downstream scripts should be trivial to change: just do a find/replace > for GCC5. > > > -- > Rebecca Cran > > > On 4/4/23 11:45 AM, Kinney, Michael D wrote: > > Changing the toolchain tag name from GCC5 to GCC will break > > EDK II CI and likely 100's of downstream developer/CI scripts. > > > > Can we keep GCC5 and add GCC that is identical to GCC5? > > > > Mike > > > >> -----Original Message----- > >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran > >> Sent: Tuesday, April 4, 2023 10:01 AM > >> To: Leif Lindholm <quic_llindhol@quicinc.com>; devel@edk2.groups.io; pedro.falcato@gmail.com > >> Cc: 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>; Gerd > >> Hoffmann <kraxel@redhat.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 4/4/23 10:32 AM, Leif Lindholm wrote: > >>> On Tue, Apr 04, 2023 at 16:57:18 +0100, Pedro Falcato wrote: > >>>> On Tue, Apr 4, 2023 at 4:49 PM Rebecca Cran <rebecca@bsdio.com> wrote: > >>>>> Okay. I'll rework the patch series to only delete GCC48 and keep GCC49 > >>>>> and GCC5. > >>>> Please rename them? There's no point in keeping their current names > >>>> anyway. I guarantee you that most people are not really able to guess > >>>> GCC49 to be the "non-LTO" flavor. > >>>> > >>>> And IMO Ard has already proved the value in non-LTO builds anyway, so > >>>> yeah. GCC and GCCNOLTO please. > >>> Agreed. I don't think there are any outstanding items that need > >>> resolving. > >>> > >>> I'd be very happy to stop hearing "you need GCC 5 in order to build > >>> edk2" misunderstandings. > >> Thanks! As a new co-maintainer I was trying to be diplomatic, but I > >> really don't see any reason to keep the existing names. > >> > >> I'll send out a v3 patch series with all the fixes I and others have > >> identified. > >> > >> > >> -- > >> Rebecca Cran > >> > >> > >> > >> > >> -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102514): https://edk2.groups.io/g/devel/message/102514 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Tue, Apr 4, 2023 at 6:52 PM Kinney, Michael D <michael.d.kinney@intel.com> wrote: > > I see value in adding a new name. > > I see no value in a non-backwards compatible change to delete/rename a fully supported one. As Leif said, you reduce all sorts of possible confusion. VS2013 builds only for Visual Studio 2013 tools, VS2017 does the same for 2017, GCC5 meanwhile builds on anything from (probably GCC 4.x, since LTO, 2011) to GCC 13 (to be released soon, 2023). Surely downstreams can adapt to *this one cosmetic change* that changes no behavior. -- Pedro -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102515): https://edk2.groups.io/g/devel/message/102515 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 4/4/23 11:57 AM, Pedro Falcato wrote: > On Tue, Apr 4, 2023 at 6:52 PM Kinney, Michael D > <michael.d.kinney@intel.com> wrote: >> I see value in adding a new name. >> >> I see no value in a non-backwards compatible change to delete/rename a fully supported one. > As Leif said, you reduce all sorts of possible confusion. > > VS2013 builds only for Visual Studio 2013 tools, VS2017 does the same > for 2017, GCC5 meanwhile builds on anything from (probably GCC 4.x, > since LTO, 2011) to GCC 13 (to be released soon, 2023). > > Surely downstreams can adapt to *this one cosmetic change* that > changes no behavior. Nope, GCC5 currently only builds on GCC _6_ and newer, since we don't specify -std=c++11. Which makes this discussion even more ridiculous IMO. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102517): https://edk2.groups.io/g/devel/message/102517 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Add GCC and leave GCC5 for now and give time for all downstream consumers to accommodate the name change. At a later date, remove GCC5. We have seen significant downstream issues on name changes in the past. Splitting into 2 different patch series allows downstream to merge in the change that adds the new name. Give time to update all dependencies to use the new name, and then at a later date remove the old name. This is a common practice to announce deprecation and support new and old for a period of time. Mike > -----Original Message----- > From: Rebecca Cran <rebecca@bsdio.com> > Sent: Tuesday, April 4, 2023 11:04 AM > To: Pedro Falcato <pedro.falcato@gmail.com>; Kinney, Michael D <michael.d.kinney@intel.com> > Cc: devel@edk2.groups.io; Leif Lindholm <quic_llindhol@quicinc.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>; Gerd Hoffmann <kraxel@redhat.com>; Feng, Bob C <bob.c.feng@intel.com>; Andrew Fish > <afish@apple.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 4/4/23 11:57 AM, Pedro Falcato wrote: > > On Tue, Apr 4, 2023 at 6:52 PM Kinney, Michael D > > <michael.d.kinney@intel.com> wrote: > >> I see value in adding a new name. > >> > >> I see no value in a non-backwards compatible change to delete/rename a fully supported one. > > As Leif said, you reduce all sorts of possible confusion. > > > > VS2013 builds only for Visual Studio 2013 tools, VS2017 does the same > > for 2017, GCC5 meanwhile builds on anything from (probably GCC 4.x, > > since LTO, 2011) to GCC 13 (to be released soon, 2023). > > > > Surely downstreams can adapt to *this one cosmetic change* that > > changes no behavior. > > Nope, GCC5 currently only builds on GCC _6_ and newer, since we don't > specify -std=c++11. Which makes this discussion even more ridiculous IMO. > > > -- > Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102532): https://edk2.groups.io/g/devel/message/102532 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
W dniu 4.04.2023 o 20:29, Michael D Kinney pisze: > Add GCC and leave GCC5 for now and give time for all downstream > consumers to accommodate the name change. > > At a later date, remove GCC5. In meantime you may also have message "GCC5 is deprecated, please switch to GCC" + few seconds delay. We handled deprecation in one project that way. For EDK2 I would add such message at start and at the end of build process. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102611): https://edk2.groups.io/g/devel/message/102611 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Thanks, deprecating it for a while makes a lot of sense. We can consider removing it in 6-12 months maybe? -- Rebecca Cran On 4/4/2023 12:29 PM, Kinney, Michael D wrote: > Add GCC and leave GCC5 for now and give time for all downstream > consumers to accommodate the name change. > > At a later date, remove GCC5. > > We have seen significant downstream issues on name changes in the > past. Splitting into 2 different patch series allows downstream > to merge in the change that adds the new name. Give time to update > all dependencies to use the new name, and then at a later date > remove the old name. > > This is a common practice to announce deprecation and support > new and old for a period of time. > > Mike > >> -----Original Message----- >> From: Rebecca Cran <rebecca@bsdio.com> >> Sent: Tuesday, April 4, 2023 11:04 AM >> To: Pedro Falcato <pedro.falcato@gmail.com>; Kinney, Michael D <michael.d.kinney@intel.com> >> Cc: devel@edk2.groups.io; Leif Lindholm <quic_llindhol@quicinc.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>; Gerd Hoffmann <kraxel@redhat.com>; Feng, Bob C <bob.c.feng@intel.com>; Andrew Fish >> <afish@apple.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 4/4/23 11:57 AM, Pedro Falcato wrote: >>> On Tue, Apr 4, 2023 at 6:52 PM Kinney, Michael D >>> <michael.d.kinney@intel.com> wrote: >>>> I see value in adding a new name. >>>> >>>> I see no value in a non-backwards compatible change to delete/rename a fully supported one. >>> As Leif said, you reduce all sorts of possible confusion. >>> >>> VS2013 builds only for Visual Studio 2013 tools, VS2017 does the same >>> for 2017, GCC5 meanwhile builds on anything from (probably GCC 4.x, >>> since LTO, 2011) to GCC 13 (to be released soon, 2023). >>> >>> Surely downstreams can adapt to *this one cosmetic change* that >>> changes no behavior. >> Nope, GCC5 currently only builds on GCC _6_ and newer, since we don't >> specify -std=c++11. Which makes this discussion even more ridiculous IMO. >> >> >> -- >> Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102533): https://edk2.groups.io/g/devel/message/102533 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Tue, 4 Apr 2023 at 20:36, Rebecca Cran <rebecca@bsdio.com> wrote: > > Thanks, deprecating it for a while makes a lot of sense. We can consider > removing it in 6-12 months maybe? > I would at least wait for a stable release to appear that supports both GCC5 and GCC/GCCNOLTO, and then perhaps queue the removal (and document it) for the subsequent one? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102552): https://edk2.groups.io/g/devel/message/102552 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Rebecca: If you plan to change GCC49 tool chain to GCCNOLTO name, I would suggest to take the same rule that adds GCCNOLTO tool chain first. We still have downstream AARCH64 platforms to use GCC49 tool chain now. Thanks Liming > -----邮件原件----- > 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Ard > Biesheuvel > 发送时间: 2023年4月5日 18:22 > 收件人: Rebecca Cran <rebecca@bsdio.com> > 抄送: Kinney, Michael D <michael.d.kinney@intel.com>; Pedro Falcato > <pedro.falcato@gmail.com>; devel@edk2.groups.io; Leif Lindholm > <quic_llindhol@quicinc.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>; Gerd Hoffmann <kraxel@redhat.com>; Feng, > Bob C <bob.c.feng@intel.com>; Andrew Fish <afish@apple.com> > 主题: 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 Tue, 4 Apr 2023 at 20:36, Rebecca Cran <rebecca@bsdio.com> wrote: > > > > Thanks, deprecating it for a while makes a lot of sense. We can consider > > removing it in 6-12 months maybe? > > > > I would at least wait for a stable release to appear that supports > both GCC5 and GCC/GCCNOLTO, and then perhaps queue the removal (and > document it) for the subsequent one? > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102574): https://edk2.groups.io/g/devel/message/102574 Mute This Topic: https://groups.io/mt/98096199/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Okay, I'll do that. Do I need to do the same with the CLANG35 and CLANG38 toolchains, marking them deprecated before removing them? -- Rebecca Cran On 4/5/23 6:57 PM, gaoliming wrote: > Rebecca: > If you plan to change GCC49 tool chain to GCCNOLTO name, I would suggest to take the same rule that adds GCCNOLTO tool chain first. > > We still have downstream AARCH64 platforms to use GCC49 tool chain now. > > Thanks > Liming >> -----邮件原件----- >> 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Ard >> Biesheuvel >> 发送时间: 2023年4月5日 18:22 >> 收件人: Rebecca Cran <rebecca@bsdio.com> >> 抄送: Kinney, Michael D <michael.d.kinney@intel.com>; Pedro Falcato >> <pedro.falcato@gmail.com>; devel@edk2.groups.io; Leif Lindholm >> <quic_llindhol@quicinc.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>; Gerd Hoffmann <kraxel@redhat.com>; Feng, >> Bob C <bob.c.feng@intel.com>; Andrew Fish <afish@apple.com> >> 主题: 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 Tue, 4 Apr 2023 at 20:36, Rebecca Cran <rebecca@bsdio.com> wrote: >>> Thanks, deprecating it for a while makes a lot of sense. We can consider >>> removing it in 6-12 months maybe? >>> >> I would at least wait for a stable release to appear that supports >> both GCC5 and GCC/GCCNOLTO, and then perhaps queue the removal (and >> document it) for the subsequent one? >> >> >> >> > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102586): https://edk2.groups.io/g/devel/message/102586 Mute This Topic: https://groups.io/mt/98096199/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Thu, 6 Apr 2023 at 04:49, Rebecca Cran <rebecca@bsdio.com> wrote: > > Okay, I'll do that. > > Do I need to do the same with the CLANG35 and CLANG38 toolchains, > marking them deprecated before removing them? > From the ARM side (as the person having introduced them in the past), I have no problems with just dropping/replacing them. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102602): https://edk2.groups.io/g/devel/message/102602 Mute This Topic: https://groups.io/mt/98096199/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Tue, 4 Apr 2023 at 20:03, Rebecca Cran <rebecca@bsdio.com> wrote: > > > On 4/4/23 11:57 AM, Pedro Falcato wrote: > > On Tue, Apr 4, 2023 at 6:52 PM Kinney, Michael D > > <michael.d.kinney@intel.com> wrote: > >> I see value in adding a new name. > >> > >> I see no value in a non-backwards compatible change to delete/rename a fully supported one. > > As Leif said, you reduce all sorts of possible confusion. > > > > VS2013 builds only for Visual Studio 2013 tools, VS2017 does the same > > for 2017, GCC5 meanwhile builds on anything from (probably GCC 4.x, > > since LTO, 2011) to GCC 13 (to be released soon, 2023). > > > > Surely downstreams can adapt to *this one cosmetic change* that > > changes no behavior. > > Nope, GCC5 currently only builds on GCC _6_ and newer, since we don't > specify -std=c++11. Which makes this discussion even more ridiculous IMO. > > I agree with Mike here. 'GCC' does not exist today, so dropping GCC5 at the same time makes this a flag day change, which is never great. Imagine having to bisect through that, and having to figure out at each step whether to use GCC5 or GCC. It's much better to have GCC5 and GCC co-exist for a little while, even if the former only exists as an alias that is documented as being obsolete and scheduled for removal. -- Ard. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102531): https://edk2.groups.io/g/devel/message/102531 Mute This Topic: https://groups.io/mt/98051589/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Sun, Apr 02, 2023 at 03:50:33PM -0600, Rebecca Cran wrote: > On 4/2/23 12:38 PM, Pedro Falcato wrote: > > As expressed off-list on UEFI talkbox, I like GCCNOLTO, but I would > > rather keep GCC5 as GCC5, for the next future iteration of "lets bump > > a new toolchain because we need feature X". > > Given we've gone from GCC 5 through 12 with no new toolchains, I'd prefer to > just have GCC. > > > This is unsurprising, plenty of NOLTO build breakage. Since no one > > seems to use this, could we think about axing this or? > > > > Just seems silly to have an extra toolchain (with extra cognitive > > overhead for anyone looking at tools_def) for s/-flto//g > > Since Liming wants to keep it, let's make all the other changes (deleting VS > 2008-2013, CLANG35, CLANG38 etc.) and keep GCCNOLTO and GCC for now. If > nobody fixes the problems with GCCNOLTO, maybe we can revisit dropping it in > a few months? I'm wondering what the point in keeping a known-broken toolchain though. It is apparently unused when nobody noticed the breakage ... take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102390): https://edk2.groups.io/g/devel/message/102390 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102391): https://edk2.groups.io/g/devel/message/102391 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102392): https://edk2.groups.io/g/devel/message/102392 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.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? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102393): https://edk2.groups.io/g/devel/message/102393 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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.
/
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102395): https://edk2.groups.io/g/devel/message/102395
Mute This Topic: https://groups.io/mt/97919856/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
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.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102397): https://edk2.groups.io/g/devel/message/102397
Mute This Topic: https://groups.io/mt/97919856/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
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. > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102398): https://edk2.groups.io/g/devel/message/102398 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Mon, 3 Apr 2023 at 15:27, Kinney, Michael D <michael.d.kinney@intel.com> wrote: > > Are the same issue(s) found with GCC5 with -b NOOPT? > None of these are found with NOOPT. Without the optimizer, GCC doesn't perform the analysis that is needed to figure out which variables are live (and valid) at which time, so it is not able to emit these diagnostics either. Note that the LTO compiler is not necessarily wrong here: it can generally see through all the function calls in a function, and so perhaps the state that the non-LTO compiler warns about is not actually reachable in the particular combination of components and libraries. However, relying on the LTO optimizer for this is fragile, and I'd much prefer having robust code that has additional checks for such states. By the same token, the LTO compiler will get rid of those if they are redundant and not needed for the program's correctness. > > > -----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. > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102399): https://edk2.groups.io/g/devel/message/102399 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 4/3/23 6:15 AM, Leif Lindholm 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. Given it's catching issues, I'd like to keep it too. In terms of CI coverage, I'd like to have both gcc 6 and gcc 12 running GCC and GCCNOLTO builds: we've already broken gcc 5 compatibility by introducing GoogleTest (which uses nullptr), so by doing builds with gcc 6 we'll be able to know when we break it and update tools_def.txt.template with a note that we'll subsequently require gcc 7. Similarly, we should also add CLANGPDB and CLANGDWARF builds. I suspect we'll rapidly run into scaling issues though, since GitHub Actions has a limit of 20 concurrent jobs on the free plan (https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration), and in order to keep CI times reasonable we'll probably want many more tasks to be running in parallel. There's a beta 'larger runners' feature (https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners), but I'm wondering if we might want to scale using something like Azure or EC2 (https://github.com/machulav/ec2-github-runner) instead, if the costs aren't going to be prohibitive? -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102396): https://edk2.groups.io/g/devel/message/102396 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
> Given it's catching issues, I'd like to keep it too. > > In terms of CI coverage, I'd like to have both gcc 6 and gcc 12 running GCC > and GCCNOLTO builds: we've already broken gcc 5 compatibility by introducing > GoogleTest (which uses nullptr), so by doing builds with gcc 6 we'll be able > to know when we break it and update tools_def.txt.template with a note that > we'll subsequently require gcc 7. So you want gcc-6 specifically or just an older version instead of latest? I could try add a RHEL-8 container (which ships gcc-8). > Similarly, we should also add CLANGPDB and CLANGDWARF builds. Fedora ships clang + llvm (version 15.0.7 right now), so adding that to the CI container should be easy. > I suspect we'll rapidly run into scaling issues though, since GitHub Actions > has a limit of 20 concurrent jobs on the free plan (https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration), > and in order to keep CI times reasonable we'll probably want many more tasks > to be running in parallel. Well, I've wondered whenever it makes sense to do _less_ stuff in parallel, to get down the constant overhead (clone repos etc). Especially with a limit on parallel jobs that could be faster in the end ... take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102402): https://edk2.groups.io/g/devel/message/102402 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 4/3/23 8:08 AM, Gerd Hoffmann wrote: > So you want gcc-6 specifically or just an older version instead of > latest? I could try add a RHEL-8 container (which ships gcc-8). I'd want the oldest version that we support, so we know when we add incompatible code. From Pedro's reply, it sounds like that'll be gcc 5 once we add -std=c++11 to tools_def.txt.template. > Well, I've wondered whenever it makes sense to do _less_ stuff in > parallel, to get down the constant overhead (clone repos etc). > Especially with a limit on parallel jobs that could be faster > in the end ... Maybe a combination? For example one task that I think could do with being split up to run in parallel is the following: stuart_ci_build -c .pytool/CISettings.py -p CryptoPkg -t DEBUG,RELEASE,NO-TARGET,NOOPT -a IA32,X64 TOOL_CHAIN_TAG=VS2019 (from https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=85605&view=logs&j=c0929384-5a08-5c0f-b36d-6f51b6b81732&t=f12d60be-1b97-57a4-b1ea-5aae2f026d4f) It shows two tasks taking 13 minutes each. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102404): https://edk2.groups.io/g/devel/message/102404 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Rebecca, I have a test PR running that splits up CodeQL analysis and builds to attempt to balance the execution times. https://github.com/tianocore/edk2/pull/4233 GitHub Actions CodeQL: * Max job time ~21 minutes * Total Action Time ~31 minutes Azure Pipelines Builds: * Max job time ~32 minutes * Total job time ~36 minutes This is a reduction of about 6 minutes from other PRs in recent history, so may be worth checkin in. There is also a dependency on the total number of agents. If we have more jobs than agents, them they get queued up and will not run until another job completes. Mike > -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran > Sent: Monday, April 3, 2023 7:28 AM > To: Gerd Hoffmann <kraxel@redhat.com> > Cc: Leif Lindholm <quic_llindhol@quicinc.com>; Ard Biesheuvel <ardb@kernel.org>; devel@edk2.groups.io; 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 4/3/23 8:08 AM, Gerd Hoffmann wrote: > > So you want gcc-6 specifically or just an older version instead of > > latest? I could try add a RHEL-8 container (which ships gcc-8). > > I'd want the oldest version that we support, so we know when we add > incompatible code. > > From Pedro's reply, it sounds like that'll be gcc 5 once we add > -std=c++11 to tools_def.txt.template. > > > > Well, I've wondered whenever it makes sense to do _less_ stuff in > > parallel, to get down the constant overhead (clone repos etc). > > Especially with a limit on parallel jobs that could be faster > > in the end ... > > Maybe a combination? For example one task that I think could do with > being split up to run in parallel is the following: > > stuart_ci_build -c .pytool/CISettings.py -p CryptoPkg -t > DEBUG,RELEASE,NO-TARGET,NOOPT -a IA32,X64 TOOL_CHAIN_TAG=VS2019 > > (from > https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=85605&view=logs&j=c0929384-5a08-5c0f-b36d- > 6f51b6b81732&t=f12d60be-1b97-57a4-b1ea-5aae2f026d4f) > > > It shows two tasks taking 13 minutes each. > > > -- > > Rebecca Cran > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102437): https://edk2.groups.io/g/devel/message/102437 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
I wonder if it might be possible to get the total time to be under 10 minutes by adding more agents? -- Rebecca Cran On 4/3/23 1:42 PM, Kinney, Michael D wrote: > Rebecca, > > I have a test PR running that splits up CodeQL analysis > and builds to attempt to balance the execution times. > > https://github.com/tianocore/edk2/pull/4233 > > GitHub Actions CodeQL: > * Max job time ~21 minutes > * Total Action Time ~31 minutes > Azure Pipelines Builds: > * Max job time ~32 minutes > * Total job time ~36 minutes > > This is a reduction of about 6 minutes from other PRs > in recent history, so may be worth checkin in. > > There is also a dependency on the total number of agents. > If we have more jobs than agents, them they get queued > up and will not run until another job completes. > > Mike > > >> -----Original Message----- >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran >> Sent: Monday, April 3, 2023 7:28 AM >> To: Gerd Hoffmann <kraxel@redhat.com> >> Cc: Leif Lindholm <quic_llindhol@quicinc.com>; Ard Biesheuvel <ardb@kernel.org>; devel@edk2.groups.io; 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 4/3/23 8:08 AM, Gerd Hoffmann wrote: >>> So you want gcc-6 specifically or just an older version instead of >>> latest? I could try add a RHEL-8 container (which ships gcc-8). >> I'd want the oldest version that we support, so we know when we add >> incompatible code. >> >> From Pedro's reply, it sounds like that'll be gcc 5 once we add >> -std=c++11 to tools_def.txt.template. >> >> >>> Well, I've wondered whenever it makes sense to do _less_ stuff in >>> parallel, to get down the constant overhead (clone repos etc). >>> Especially with a limit on parallel jobs that could be faster >>> in the end ... >> Maybe a combination? For example one task that I think could do with >> being split up to run in parallel is the following: >> >> stuart_ci_build -c .pytool/CISettings.py -p CryptoPkg -t >> DEBUG,RELEASE,NO-TARGET,NOOPT -a IA32,X64 TOOL_CHAIN_TAG=VS2019 >> >> (from >> https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=85605&view=logs&j=c0929384-5a08-5c0f-b36d- >> 6f51b6b81732&t=f12d60be-1b97-57a4-b1ea-5aae2f026d4f) >> >> >> It shows two tasks taking 13 minutes each. >> >> >> -- >> >> Rebecca Cran >> >> >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102438): https://edk2.groups.io/g/devel/message/102438 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Some of the longer execution jobs can be easily broken up into smaller pieces. 20 min may be a more realistic goal no matter how many agents are available. But would still require a lot of effort to implement caches and rebalance and tune. Mike > -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran > Sent: Monday, April 3, 2023 12:55 PM > To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Gerd Hoffmann <kraxel@redhat.com> > Cc: Leif Lindholm <quic_llindhol@quicinc.com>; Ard Biesheuvel <ardb@kernel.org>; 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> > 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 > > I wonder if it might be possible to get the total time to be under 10 > minutes by adding more agents? > > > -- > > Rebecca Cran > > > On 4/3/23 1:42 PM, Kinney, Michael D wrote: > > Rebecca, > > > > I have a test PR running that splits up CodeQL analysis > > and builds to attempt to balance the execution times. > > > > https://github.com/tianocore/edk2/pull/4233 > > > > GitHub Actions CodeQL: > > * Max job time ~21 minutes > > * Total Action Time ~31 minutes > > Azure Pipelines Builds: > > * Max job time ~32 minutes > > * Total job time ~36 minutes > > > > This is a reduction of about 6 minutes from other PRs > > in recent history, so may be worth checkin in. > > > > There is also a dependency on the total number of agents. > > If we have more jobs than agents, them they get queued > > up and will not run until another job completes. > > > > Mike > > > > > >> -----Original Message----- > >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran > >> Sent: Monday, April 3, 2023 7:28 AM > >> To: Gerd Hoffmann <kraxel@redhat.com> > >> Cc: Leif Lindholm <quic_llindhol@quicinc.com>; Ard Biesheuvel <ardb@kernel.org>; devel@edk2.groups.io; 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 4/3/23 8:08 AM, Gerd Hoffmann wrote: > >>> So you want gcc-6 specifically or just an older version instead of > >>> latest? I could try add a RHEL-8 container (which ships gcc-8). > >> I'd want the oldest version that we support, so we know when we add > >> incompatible code. > >> > >> From Pedro's reply, it sounds like that'll be gcc 5 once we add > >> -std=c++11 to tools_def.txt.template. > >> > >> > >>> Well, I've wondered whenever it makes sense to do _less_ stuff in > >>> parallel, to get down the constant overhead (clone repos etc). > >>> Especially with a limit on parallel jobs that could be faster > >>> in the end ... > >> Maybe a combination? For example one task that I think could do with > >> being split up to run in parallel is the following: > >> > >> stuart_ci_build -c .pytool/CISettings.py -p CryptoPkg -t > >> DEBUG,RELEASE,NO-TARGET,NOOPT -a IA32,X64 TOOL_CHAIN_TAG=VS2019 > >> > >> (from > >> https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=85605&view=logs&j=c0929384-5a08-5c0f-b36d- > >> 6f51b6b81732&t=f12d60be-1b97-57a4-b1ea-5aae2f026d4f) > >> > >> > >> It shows two tasks taking 13 minutes each. > >> > >> > >> -- > >> > >> Rebecca Cran > >> > >> > >> > >> > >> > >> > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102439): https://edk2.groups.io/g/devel/message/102439 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Mon, Apr 3, 2023 at 1:27 PM Rebecca Cran <rebecca@bsdio.com> wrote:
>
> In terms of CI coverage, I'd like to have both gcc 6 and gcc 12 running
> GCC and GCCNOLTO builds: we've already broken gcc 5 compatibility by
> introducing GoogleTest (which uses nullptr), so by doing builds with gcc
> 6 we'll be able to know when we break it and update
> tools_def.txt.template with a note that we'll subsequently require gcc 7.
FYI, GCC 5 supports nullptr and the whole of C++11. I think the
problem is that the .inf doesn't force C++11 through -std={gnu,
c}++11, which makes gcc 5 use its default C++ standard.
Which, IIRC, was C++98 until gcc 6 or 7 (and 98 does not have nullptr).
--
Pedro
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102400): https://edk2.groups.io/g/devel/message/102400
Mute This Topic: https://groups.io/mt/97919856/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
On 4/3/23 7:44 AM, Pedro Falcato wrote:
> On Mon, Apr 3, 2023 at 1:27 PM Rebecca Cran <rebecca@bsdio.com> wrote:
>> In terms of CI coverage, I'd like to have both gcc 6 and gcc 12 running
>> GCC and GCCNOLTO builds: we've already broken gcc 5 compatibility by
>> introducing GoogleTest (which uses nullptr), so by doing builds with gcc
>> 6 we'll be able to know when we break it and update
>> tools_def.txt.template with a note that we'll subsequently require gcc 7.
> FYI, GCC 5 supports nullptr and the whole of C++11. I think the
> problem is that the .inf doesn't force C++11 through -std={gnu,
> c}++11, which makes gcc 5 use its default C++ standard.
> Which, IIRC, was C++98 until gcc 6 or 7 (and 98 does not have nullptr).
Ah, thanks! We _do_ need to start specifying which C and C++ standards
we're building against, since relying on defaults gets us into problems
like this.
--
Rebecca Cran
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102401): https://edk2.groups.io/g/devel/message/102401
Mute This Topic: https://groups.io/mt/97919856/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
On Sun, 2 Apr 2023 at 17:41, Rebecca Cran <rebecca@bsdio.com> wrote: > > On 3/28/23 7:19 PM, gaoliming wrote: > > > GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC tool chain with LTO enable option. > > > > They have the different usage. I suggest to keep GCC49 and GCC5 both, and also keep their name as is. > > Is anything still _using_ GCC49 though? Since I strongly suspect nobody > is using gcc 4.9, I'll rename it to GCCNOLTO. > > When I try and build OVMF with it, I get the following error: > > > /UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c: > In function ‘InternalSetPageState’: > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:166:37: > error: ‘Cmd’ may be used uninitialized in this function > [-Werror=maybe-uninitialized] > 166 | Info->Entry[i].CurrentPage = 0; > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:32:10: > note: ‘Cmd’ was declared here > 32 | UINTN Cmd; > | ^~~ > rm -f > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > "ar" cr > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > @/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/object_files.lst > cc1: all warnings being treated as errors > make: *** [GNUmakefile:304: > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib/OUTPUT/X64/SnpPageStateChangeInternal.obj] > Error 1 > > > build.py... > : error 7000: Failed to execute command > make tbuild > [/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib] > > > build.py... > : error F002: Failed to build module > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf [X64, GCC49, RELEASE] > > - Failed - > Build end time: 09:38:34, Apr.02 2023 > Build total time: 00:00:14 > That warning seems reasonable to me: Cmd may be uninitialized, and only under LTO do we get sufficient optimization and inlining for the code generator to be able to infer that the 'default' case is unreachable. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102362): https://edk2.groups.io/g/devel/message/102362 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
NOOPT builds can be very valuable to find these types of issues. Mike > -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ard Biesheuvel > Sent: Sunday, April 2, 2023 9:37 AM > To: Rebecca Cran <rebecca@bsdio.com> > Cc: Gao, Liming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io; 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>; Gerd > Hoffmann <kraxel@redhat.com>; Feng, Bob C <bob.c.feng@intel.com>; Andrew Fish <afish@apple.com>; Leif Lindholm > <quic_llindhol@quicinc.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 Sun, 2 Apr 2023 at 17:41, Rebecca Cran <rebecca@bsdio.com> wrote: > > > > On 3/28/23 7:19 PM, gaoliming wrote: > > > > > GCC49 is one GCC tool chain without LTO enable option. GCC5 is another GCC tool chain with LTO enable option. > > > > > > They have the different usage. I suggest to keep GCC49 and GCC5 both, and also keep their name as is. > > > > Is anything still _using_ GCC49 though? Since I strongly suspect nobody > > is using gcc 4.9, I'll rename it to GCCNOLTO. > > > > When I try and build OVMF with it, I get the following error: > > > > > > /UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c > > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c: > > In function ‘InternalSetPageState’: > > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:166:37: > > error: ‘Cmd’ may be used uninitialized in this function > > [-Werror=maybe-uninitialized] > > 166 | Info->Entry[i].CurrentPage = 0; > > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ > > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c:32:10: > > note: ‘Cmd’ was declared here > > 32 | UINTN Cmd; > > | ^~~ > > rm -f > > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > > "ar" cr > > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/DxeIpIoLib.lib > > > @/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib/OUTPUT/object_files.ls > t > > cc1: all warnings being treated as errors > > make: *** [GNUmakefile:304: > > > /home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib/OUTPUT/ > X64/SnpPageStateChangeInternal.obj] > > Error 1 > > > > > > build.py... > > : error 7000: Failed to execute command > > make tbuild > > [/home/bcran/src/uefi/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib] > > > > > > build.py... > > : error F002: Failed to build module > > /home/bcran/src/uefi/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf [X64, GCC49, RELEASE] > > > > - Failed - > > Build end time: 09:38:34, Apr.02 2023 > > Build total time: 00:00:14 > > > > That warning seems reasonable to me: Cmd may be uninitialized, and > only under LTO do we get sufficient optimization and inlining for the > code generator to be able to infer that the 'default' case is > unreachable. > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102363): https://edk2.groups.io/g/devel/message/102363 Mute This Topic: https://groups.io/mt/97919856/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2024 Red Hat, Inc.