Bug 1171643

Summary: GCC 10: ovmf build fails
Product: [openSUSE] openSUSE Tumbleweed Reporter: Forgotten User 7645792743 <forgotten_7645792743>
Component: Virtualization:OtherAssignee: 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
i build ovmf as part of my obs qemu/etc build

  https://build.opensuse.org/project/show/home:pgnd:Virtualization:qemu

builds with gcc9 have been working great for a _long_ time.

following/testing the GCC10-compatibility META

  Bug 1157217 - [META] GCC 10 package failures
   https://bugzilla.opensuse.org/show_bug.cgi?id=1157217

qemu builds w/ gcc10 were recently fixed

  Bug 1169728 - GCC 10: qemu build fails
   https://bugzilla.opensuse.org/show_bug.cgi?id=1169728

when I switch MY build to gcc10, ovmf build fails.

here's the GCC10+ovmf build log

  https://paste.opensuse.org/949a8539

so far, I can additionally verify that switching BACK to gcc9 cures the failed-build problem;

i.e., gcc9 build's OK == "succeeded". status here:

 https://build.opensuse.org/project/show/home:pgnd:Virtualization:qemu

i understand that's a different statement than gcc10 _is_ the problem.
Comment 1 Martin Liška 2020-05-14 07:23:22 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}
Comment 2 Gary Ching-Pang Lin 2020-05-14 07:33:30 UTC
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.
Comment 3 Forgotten User 7645792743 2020-05-16 04:41:32 UTC
wasn't clear ...

did you need some add'l info from my end?
Comment 4 Gary Ching-Pang Lin 2020-05-18 01:35:39 UTC
(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.
Comment 5 Forgotten User 7645792743 2020-05-18 02:59:30 UTC
> 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?
Comment 6 Gary Ching-Pang Lin 2020-05-18 03:24:29 UTC
(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.
Comment 7 Forgotten User 7645792743 2020-05-18 04:16:24 UTC
> 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
Comment 8 Gary Ching-Pang Lin 2020-05-18 05:32:00 UTC
(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.
Comment 9 Martin Liška 2020-05-18 06:50:26 UTC
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.
Comment 10 Gary Ching-Pang Lin 2020-05-18 07:07:44 UTC
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)
Comment 11 Gary Ching-Pang Lin 2020-05-18 07:09:27 UTC
(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.
Comment 13 Gary Ching-Pang Lin 2020-05-19 01:18:41 UTC
(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.
Comment 14 Forgotten User 7645792743 2020-05-19 01:40:09 UTC
pls drop a link to the upstream report here when you do
Comment 15 Gary Ching-Pang Lin 2020-05-19 02:10:49 UTC
Filed an upstream bug: https://bugzilla.tianocore.org/show_bug.cgi?id=2723
Comment 16 Forgotten User 7645792743 2020-05-19 02:55:34 UTC
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 ...
Comment 17 Gary Ching-Pang Lin 2020-05-19 03:40:10 UTC
(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...
Comment 18 Martin Liška 2020-05-19 05:56:21 UTC
@pgnd_: Can you please submit the changes to Virtualization/ovmf project?
Comment 19 Gary Ching-Pang Lin 2020-05-19 06:34:00 UTC
(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".
Comment 20 Martin Liška 2020-05-19 10:11:19 UTC
(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?
Comment 21 Forgotten User 7645792743 2020-05-19 17:25:17 UTC
(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?
Comment 22 Gary Ching-Pang Lin 2020-05-20 03:28:01 UTC
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?
Comment 23 Forgotten User 7645792743 2020-05-20 04:30:43 UTC
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
Comment 24 Gary Ching-Pang Lin 2020-05-20 05:15:51 UTC
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.
Comment 25 Forgotten User 7645792743 2020-05-20 05:59:43 UTC
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
Comment 26 Gary Ching-Pang Lin 2020-05-20 07:03:54 UTC
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
Comment 27 Martin Liška 2020-05-20 08:16:20 UTC
(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
Comment 28 Gary Ching-Pang Lin 2020-05-20 08:45:17 UTC
(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
Comment 29 Martin Liška 2020-05-20 08:56:01 UTC
Ah, ok. Thanks for the clarification.
Let's wait for an upstream fix then.
Comment 30 Martin Liška 2020-05-20 10:14:46 UTC
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?
Comment 31 Gary Ching-Pang Lin 2020-05-21 03:43:07 UTC
(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.
Comment 32 Gary Ching-Pang Lin 2020-05-21 07:10:25 UTC
(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.
Comment 33 Gary Ching-Pang Lin 2020-05-21 07:14:33 UTC
Submitted the workaround.
https://build.opensuse.org/request/show/807896
Comment 34 Martin Liška 2020-05-21 07:24:30 UTC
Thank you for the workaround!
Comment 35 Martin Liška 2020-05-21 09:40:15 UTC
Fixed in development project.
Comment 36 Forgotten User 7645792743 2020-05-21 14:05:55 UTC
ovmf + gcc10 build's good:

https://build.opensuse.org/package/show/home:pgnd:Virtualization:qemu-gcc10/ovmf

thx! o/
Comment 37 Forgotten User 7645792743 2020-05-21 14:07:54 UTC
ovmf + gcc10 build's good:

https://build.opensuse.org/package/show/home:pgnd:Virtualization:qemu-gcc10/ovmf

thx! o/