|
Bugzilla – Full Text Bug Listing |
| Summary: | GCC 10: ovmf build fails | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Forgotten User 7645792743 <forgotten_7645792743> |
| Component: | Virtualization:Other | Assignee: | Gary Ching-Pang Lin <glin> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | glin, martin.liska |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| See Also: | https://bugzilla.tianocore.org/show_bug.cgi?id=2723 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 1157217 | ||
| Attachments: |
Testing patch for moutline-atomics
Disable stdc atomic disable stdc atomics |
||
|
Description
Forgotten User 7645792743
2020-05-14 06:48:45 UTC
Ok, so the failure is:
[ 897s] /usr/lib64/gcc/aarch64-suse-linux/10/ld: /tmp/SecureBootConfigDxe.dll.TGvO1O.ltrans1.ltrans.o: in function `getrn.lto_priv.0':
[ 897s] /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202002/CryptoPkg/Library/OpensslLib/openssl/crypto/lhash/lhash.c:303: undefined reference to `__aarch64_ldadd8_relax'
[ 897s] /usr/lib64/gcc/aarch64-suse-linux/10/ld: /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202002/CryptoPkg/Library/OpensslLib/openssl/crypto/lhash/lhash.c:313: undefined reference to `__aarch64_ldadd8_relax'
[ 897s] /usr/lib64/gcc/aarch64-suse-linux/10/ld: /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202002/CryptoPkg/Library/OpensslLib/openssl/crypto/lhash/lhash.c:318: undefined reference to `__aarch64_ldadd8_relax'
[ 897s] /usr/lib64/gcc/aarch64-suse-linux/10/ld: /tmp/SecureBootConfigDxe.dll.TGvO1O.ltrans1.ltrans.o: in function `OPENSSL_LH_retrieve':
[ 897s] /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202002/CryptoPkg/Library/OpensslLib/openssl/crypto/lhash/lhash.c:171: undefined reference to `__aarch64_ldadd8_relax'
[ 897s] /usr/lib64/gcc/aarch64-suse-linux/10/ld: /tmp/SecureBootConfigDxe.dll.TGvO1O.ltrans5.ltrans.o: in function `CRYPTO_DOWN_REF.constprop.0':
[ 897s] /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202002/CryptoPkg/Library/OpensslLib/openssl/include/internal/refcount.h:50: undefined reference to `__aarch64_ldadd4_relax'
[ 897s] /usr/lib64/gcc/aarch64-suse-linux/10/ld: /tmp/SecureBootConfigDxe.dll.TGvO1O.ltrans5.ltrans.o: in function `EVP_PKEY_up_ref.isra.0':
[ 897s] /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202002/CryptoPkg/Library/OpensslLib/openssl/include/internal/refcount.h:34: undefined reference to `__aarch64_ldadd4_relax'
I can't find the functions in the source files? Can you please test:
%define _lto_cflags %{nil}
Changing _lto_cflags won't work since ovmf doesn't take any cflags from OBS. To turn off the lto flags, you have to change the TOOL_CHAIN variable in the spec file from GCC5 to GCC49. On the other hand, the build failure seems only happening with the aarch64 cross-compiler. The x86_64 part is finished successfully. wasn't clear ... did you need some add'l info from my end? (In reply to pgnd _ from comment #3) > wasn't clear ... > > did you need some add'l info from my end? Please modify ovmf.spec a bit. Just one line: %if 0%{?suse_version} > 1320 -TOOL_CHAIN=GCC5 +TOOL_CHAIN=GCC49 %else OVMF enables LTO for gcc >= 5.0, so we have to specify a version lower than 5.0 to disable LTO flags. > Please modify ovmf.spec a bit. done here https://build.opensuse.org/package/rdiff/home:pgnd:Virtualization:qemu/ovmf?opackage=ovmf&oproject=Virtualization&rev=5 building now. is that^ the right long term fix, though? or just a workaround? (In reply to pgnd _ from comment #5) > > Please modify ovmf.spec a bit. > > done here > > https://build.opensuse.org/package/rdiff/home:pgnd:Virtualization:qemu/ > ovmf?opackage=ovmf&oproject=Virtualization&rev=5 > > building now. > > is that^ the right long term fix, though? > > or just a workaround? It's a workaround. Just want to know whether the failure is caused by LTO or not. > It's a workaround. Just want to know whether the failure is caused by LTO or not with the change to spec as you'd suggested, my ovmf build still fails log @ https://paste.opensuse.org/fb3263a1 (In reply to pgnd _ from comment #7) > > It's a workaround. Just want to know whether the failure is caused by LTO or not > > with the change to spec as you'd suggested, my ovmf build still fails > > log @ > > https://paste.opensuse.org/fb3263a1 So LTO doesn't matter. Have to figure out how openssl generates __aarch64_ldadd4_relax and __aarch64_ldadd8_relax. So the missing symbols would be caused by: ``` The option -moutline-atomics has been added to aid deployment of the Large System Extensions (LSE) on GNU/Linux systems built with a baseline architecture targeting Armv8-A. When the option is specified code is emitted to detect the presence of LSE instructions at runtime and use them for standard atomic operations. For more information please refer to the documentation. ``` So please add -mno-outline-atomics for aarch64 compile flags. Created attachment 837901 [details]
Testing patch for moutline-atomics
The patch adds "-moutline-atomics" to GCC5 flags. Please set TOOL_CHAIN back to gcc5 and apply the patch for the further test.
If that patch works, I'll ping edk2/ovmf upstream to find a better place for the flag. (Maybe a new set of variables for GCC10)
(In reply to Gary Ching-Pang Lin from comment #10) > Created attachment 837901 [details] > Testing patch for moutline-atomics ^^^^^^^^^^^^^^^^ > > The patch adds "-moutline-atomics" to GCC5 flags. Please set TOOL_CHAIN back ^^^^^^^^^^^^^^^^^ > to gcc5 and apply the patch for the further test. > > If that patch works, I'll ping edk2/ovmf upstream to find a better place for > the flag. (Maybe a new set of variables for GCC10) Typos... It's actually -mno-outline-atomics. patched, https://build.opensuse.org/package/rdiff/home:pgnd:Virtualization:qemu/ovmf?opackage=ovmf&oproject=Virtualization&rev=11 ovmf build with gcc10 succeeds https://build.opensuse.org/package/show/home:pgnd:Virtualization:qemu/ovmf (In reply to pgnd _ from comment #12) > patched, > > https://build.opensuse.org/package/rdiff/home:pgnd:Virtualization:qemu/ > ovmf?opackage=ovmf&oproject=Virtualization&rev=11 > > ovmf build with gcc10 succeeds > > https://build.opensuse.org/package/show/home:pgnd:Virtualization:qemu/ovmf Thanks! I'll report the issue to edk2 upstream. pls drop a link to the upstream report here when you do Filed an upstream bug: https://bugzilla.tianocore.org/show_bug.cgi?id=2723 thx. note that the paste i provided, and you referenced in your upstream post https://paste.opensuse.org/949a8539 expires "in 1 day". for convenience, i recreated it with a 3month expiry, https://paste.opensuse.org/6607e593 might want to post that upstream ... (In reply to pgnd _ from comment #16) > thx. > > note that the paste i provided, and you referenced in your upstream post > > https://paste.opensuse.org/949a8539 > > expires "in 1 day". > > for convenience, i recreated it with a 3month expiry, > > https://paste.opensuse.org/6607e593 > > might want to post that upstream ... Thanks! I didn't notice the expiration day... @pgnd_: Can you please submit the changes to Virtualization/ovmf project? (In reply to Martin Liška from comment #18) > @pgnd_: Can you please submit the changes to Virtualization/ovmf project? The patch would need a conditional check for gcc version or it will break the build using gcc without "-mno-outline-atomics". (In reply to Gary Ching-Pang Lin from comment #19) > (In reply to Martin Liška from comment #18) > > @pgnd_: Can you please submit the changes to Virtualization/ovmf project? > > The patch would need a conditional check for gcc version or it will break > the build using gcc without "-mno-outline-atomics". Yes, it sounds like a configure detection. I bet the project does similar detection for other options/features, right? (In reply to Martin Liška from comment #18) > @pgnd_: Can you please submit the changes to Virtualization/ovmf project? sure, but still needed? iiuc, upstream changes -- with, I assume, the mentioned 'conditional' -- will get pulled in ... or do you prefer this band-in submitted to Virtualization/ovmf now/as-is? Created attachment 838002 [details]
Disable stdc atomic
The upstream maintainer suggests to define __STDC_NO_ATOMICS__ for openssl.
@pgnd Would you mind to try the attached patch?
had to make trivial mods to your patch to not fail to apply to current src @ obs this https://build.opensuse.org/package/view_file/home:pgnd:Virtualization:qemu/ovmf/pgnd-boo1171643.no-atomics.patch _does_ now apply assuming I didn't screw up the patch (mod'd on my tiny phone screen), it doesn't see to solve the build issue. ovmf build with gcc10 fails again build log here: https://paste.opensuse.org/ec3ef796 Created attachment 838004 [details]
disable stdc atomics
Sorry, I used the latest git master to generate the patch and didn't expect the RISCV ccflags. Recreate the patch with the tarball in Virtualization/ovmf.
Please try the attached patch.
with your latest patch -- which looks the same as what I mod'd/applied in last msg -- the build still FAILs build log's here: https://paste.opensuse.org/926b83d9 I did a few tests with local build and found that __STDC_NO_ATOMICS__ seems not working. Take CRYPTO_UP_REF() as an example, it replaces atomic_fetch_add_explicit() with __atomic_fetch_add() when __STDC_NO_ATOMICS__ is defined. However, per stdatomic.h(*), atomic_fetch_add_explicit() is actually an alias of __atomic_fetch_add(). Will raise the problem to upstream. (*) /usr/lib64/gcc/x86_64-suse-linux/10/include/stdatomic.h (In reply to Gary Ching-Pang Lin from comment #26) > I did a few tests with local build and found that __STDC_NO_ATOMICS__ seems > not working. Take CRYPTO_UP_REF() as an example, it replaces > atomic_fetch_add_explicit() with __atomic_fetch_add() when > __STDC_NO_ATOMICS__ is defined. However, per stdatomic.h(*), > atomic_fetch_add_explicit() is actually an alias of __atomic_fetch_add(). > Will raise the problem to upstream. Can you please send a link to the bug? Btw. what's the problem with the addition of -mno-outline-atomics option? > > (*) /usr/lib64/gcc/x86_64-suse-linux/10/include/stdatomic.h (In reply to Martin Liška from comment #27) > (In reply to Gary Ching-Pang Lin from comment #26) > > I did a few tests with local build and found that __STDC_NO_ATOMICS__ seems > > not working. Take CRYPTO_UP_REF() as an example, it replaces > > atomic_fetch_add_explicit() with __atomic_fetch_add() when > > __STDC_NO_ATOMICS__ is defined. However, per stdatomic.h(*), > > atomic_fetch_add_explicit() is actually an alias of __atomic_fetch_add(). > > Will raise the problem to upstream. > > Can you please send a link to the bug? > It's mentioned in comment#15: https://bugzilla.tianocore.org/show_bug.cgi?id=2723 I added the link to "See Also" to make it easier to be found. > Btw. what's the problem with the addition of -mno-outline-atomics option? > The upstream maintainer thought applying __STDC_NO_ATOMICS__ to openssl for all gcc versions would work, and it turned out not. Since edk2/ovmf catalogues all gcc versions above 5 as GCC5, it's not feasible just adding -mno-outline-atomics to GCC5 cflags directly. I guess upstream will add a new GCC10 family to BaseTools/Conf/tools_def.template in end. > > > > (*) /usr/lib64/gcc/x86_64-suse-linux/10/include/stdatomic.h Ah, ok. Thanks for the clarification. Let's wait for an upstream fix then. We're approaching a successful staging project for GCC10 and it seems this one is last missing blocker. Do we have a work-around that can help us now? (In reply to Martin Liška from comment #30) > We're approaching a successful staging project for GCC10 and it seems this > one is last missing blocker. > Do we have a work-around that can help us now? We can have a workaround like this: https://build.opensuse.org/package/rdiff/home:gary_lin:branches:Virtualization/ovmf?linkrev=base&rev=2 Detect the default gcc version and apply the patch conditionally. (In reply to Gary Ching-Pang Lin from comment #31) > (In reply to Martin Liška from comment #30) > > We're approaching a successful staging project for GCC10 and it seems this > > one is last missing blocker. > > Do we have a work-around that can help us now? > > We can have a workaround like this: > https://build.opensuse.org/package/rdiff/home:gary_lin:branches: > Virtualization/ovmf?linkrev=base&rev=2 > > Detect the default gcc version and apply the patch conditionally. It seems that there is no good fix ATM. Will submit the workaround first and follow up the upstream fix. Submitted the workaround. https://build.opensuse.org/request/show/807896 Thank you for the workaround! Fixed in development project. ovmf + gcc10 build's good: https://build.opensuse.org/package/show/home:pgnd:Virtualization:qemu-gcc10/ovmf thx! o/ ovmf + gcc10 build's good: https://build.opensuse.org/package/show/home:pgnd:Virtualization:qemu-gcc10/ovmf thx! o/ |