Bug 2071038

Summary: Building with -mcpu=native on new Arm type fails
Product: Red Hat Enterprise Linux 9 Reporter: Nick Clifton <nickc>
Component: binutilsAssignee: Nick Clifton <nickc>
binutils sub component: system-version QA Contact: Miloš Prchlík <mprchlik>
Status: CLOSED ERRATA Docs Contact:
Severity: high    
Priority: unspecified CC: ahajkova, bgray, dmalcolm, dshaks, efuller, frival, fweimer, gcase, jakub, jbastian, mcermak, mprchlik, nickc, ohudlick, qe-baseos-tools-bugs, sipoyare, tumeya, vkadlcik
Version: 9.0Keywords: FutureFeature, Triaged
Target Milestone: rc   
Target Release: ---   
Hardware: aarch64   
OS: Linux   
Whiteboard:
Fixed In Version: binutils-2.35.2-23.el9 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: 2056691 Environment:
Last Closed: 2022-11-15 11:12:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2056691    
Bug Blocks:    

Comment 1 Nick Clifton 2022-04-05 13:05:48 UTC
Fixed in binutils-2.35.2-20.el9

Comment 5 Miloš Prchlík 2022-05-19 12:11:39 UTC
According to applied patches, the original issue might be fixed. However, I am unable to verify it with the reproducer I have, because its output does not match the one seen on RHEL-8.6.0 in https://bugzilla.redhat.com/show_bug.cgi?id=2056691.

$ cat flags
processor       : 0
BogoMIPS        : 2100.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm ssbs dcpodp svei8mm svebf16 i8mm bf16 dgh rng
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x1
CPU part        : 0xd40
CPU revision    : 1
$ rpm -q binutils
binutils-2.35.2-17.el9.aarch64
$ GCC_CPUINFO=flags gcc x.c -mcpu=native
Assembler messages:
Error: unknown architectural extension `pauth'
Error: unrecognized option -march=armv8.4-a+crypto+rcpc+sha3+sm4+sve+rng+ssbs+i8mm+bf16+nodotprod+nopauth
$ 

I am seeing the same output with binutils-2.35.2-21.el9.aarch64:

$ dnf install -y http://download.eng.bos.redhat.com/brewroot/vol/rhel-9/packages/binutils/2.35.2/21.el9/aarch64/binutils-2.35.2-21.el9.aarch64.rpm
...
$ rpm -q binutils
binutils-2.35.2-21.el9.aarch64
$ GCC_CPUINFO=flags gcc x.c -mcpu=native
Assembler messages:
Error: unknown architectural extension `pauth'
Error: unrecognized option -march=armv8.4-a+crypto+rcpc+sha3+sm4+sve+rng+ssbs+i8mm+bf16+nodotprod+nopauth
$ 


The expected output is the following:

Error: unknown architectural extension `rng+nodotprod+nofp16fml'
Error: unrecognized option -march=armv8.4-a+crypto+rcpc+sha3+sm4+sve+rng+nodotprod+nofp16fml

Seems to me the reproducer is hit by another unsupported extension. Nick, would you be able to help me out here? Is there a way I could disable binutils' desire to add "nopauth"? I tried to run gcc with `-march=armv8.4-a+crypto+rcpc+sha3+sm4+sve+rng+ssbs+i8mm+bf16+nodotprod` instead of `-mcpu=native`, but that passes with both old and new binutils, so I gained nothing from this attempt.

Comment 6 Miloš Prchlík 2022-05-21 08:21:33 UTC
Bumping ITM to gain more time for verification.

Comment 7 Nick Clifton 2022-05-23 08:40:06 UTC
(In reply to Miloš Prchlík from comment #5)

Hi Miloš,

> $ GCC_CPUINFO=flags gcc x.c -mcpu=native

> Error: unknown architectural extension `pauth'
> Error: unrecognized option
> -march=armv8.4-a+crypto+rcpc+sha3+sm4+sve+rng+ssbs+i8mm+bf16+nodotprod+nopauth

 
> Seems to me the reproducer is hit by another unsupported extension.

Agreed.

> Nick, would you be able to help me out here? Is there a way I could disable
> binutils' desire to add "nopauth"?

No. :-(  In fact it is not the binutils that is adding the option, it is GCC.  The GCC driver program constructs the command line that is passed to the assembler, so this is where the +nopauth comes from.

What is happening is that gcc is seeing the -mcpu=native option on the command line, which causes it to scan /proc/cpuinfo looking for the Features field.  It then converts the each entry FOO in this field into a +FOO appended to the end of the -march= command.  In addition if gcc happens to know about a AArch64 architectural extension BAR, but BAR is not mentioned in the Features field then it adds +noBAR to the -march= command line option.  So this is where the problem lies. GCC knows about the "pauth" extension, but the host processor does not.  So GCC adds +nopauth to the command line, which is then rejected by the assembler (since it does not know about "pauth" either).

I see two ways forwards ...

  1. Change the assembler so that it does not complain about +noXXX architectural extensions.  Since this option is just disabling a feature and the assembler does not even know how to support the feature, complaining about is basically redundant.

  2. Change GCC so that it does not add +noXXX to the command line for extensions that are not supported by the host cpu.

Since this is currently a binutils BZ and it will be pretty easy for me to make the change, lets go with option 1.

Changing to ASSIGNED.

Comment 8 Nick Clifton 2022-05-23 10:55:03 UTC
Fixed in binutils-2.35.2-23.el9

Comment 9 Miloš Prchlík 2022-06-03 07:52:26 UTC
(In reply to Nick Clifton from comment #7)
> (In reply to Miloš Prchlík from comment #5)
> 
> Hi Miloš,
> 
> > $ GCC_CPUINFO=flags gcc x.c -mcpu=native
> 
> > Error: unknown architectural extension `pauth'
> > Error: unrecognized option
> > -march=armv8.4-a+crypto+rcpc+sha3+sm4+sve+rng+ssbs+i8mm+bf16+nodotprod+nopauth
> 
>  
> > Seems to me the reproducer is hit by another unsupported extension.
> 
> Agreed.
> 
> > Nick, would you be able to help me out here? Is there a way I could disable
> > binutils' desire to add "nopauth"?
> 
> No. :-(  In fact it is not the binutils that is adding the option, it is
> GCC.  The GCC driver program constructs the command line that is passed to
> the assembler, so this is where the +nopauth comes from.
> 
> What is happening is that gcc is seeing the -mcpu=native option on the
> command line, which causes it to scan /proc/cpuinfo looking for the Features
> field.  It then converts the each entry FOO in this field into a +FOO
> appended to the end of the -march= command.  In addition if gcc happens to
> know about a AArch64 architectural extension BAR, but BAR is not mentioned
> in the Features field then it adds +noBAR to the -march= command line
> option.  So this is where the problem lies. GCC knows about the "pauth"
> extension, but the host processor does not.  So GCC adds +nopauth to the
> command line, which is then rejected by the assembler (since it does not
> know about "pauth" either).
> 
> I see two ways forwards ...
> 
>   1. Change the assembler so that it does not complain about +noXXX
> architectural extensions.  Since this option is just disabling a feature and
> the assembler does not even know how to support the feature, complaining
> about is basically redundant.
> 
>   2. Change GCC so that it does not add +noXXX to the command line for
> extensions that are not supported by the host cpu.
> 
> Since this is currently a binutils BZ and it will be pretty easy for me to
> make the change, lets go with option 1.
> 
> Changing to ASSIGNED.


Understood, thanks for explanation.

Comment 12 Miloš Prchlík 2022-06-03 09:17:39 UTC
Verified with binutils-2.35.2-23.el9:

$ rpm -q binutils
binutils-2.35.2-23.el9.aarch64
$ GCC_CPUINFO=flags gcc x.c -mcpu=native
$ file a.out
a.out: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=42d6fcf0ae6418fadf5b83ee810826eefe805fb2, for GNU/Linux 3.7.0, not stripped
$

Comment 16 errata-xmlrpc 2022-11-15 11:12:58 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (binutils bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8281