Khem Raj 754345d606 feature-arm-crypto: Add +nocrypto to -mcpu when crypto not in features
When crypto is not in tune features then add +nocryto to
-mcpu explicitly. This makes the behavior between clang
and gcc match. Currently -mcpu=cortex-a72 has different
behavior in clang and gcc in terms of what features are
considered default. Clang enables different set of common
features than gcc on other hand. For example clang
enables crypto with default set but gcc
does not, gcc recommends to disable unavailable extensions
in -mcpu [1] explicitly. crypto is optional on cortex-a53
and cortex-a72. This is not as common but Broadcom
SOCs in raspberrypi3/4 have dropped crypto for cost
reasons [2]. This results in illegal instruction
traps [3] [4] when building components e.g. chromium,
qtwebengine, weston etc. with clang using -mcpu=cortex-a72
for rpi4 target.

Adding +nocrypto makes clang behave like gcc does today. We
do have separate tune if crypto enabled cortex-a72 cores
are to be targeted (cortexa72-cryto) as DEFAULTTUNE

They are added to default feature file since crypto extension
is available in multiple arm architecture versions e.g. armv8,
armv9. It is optional extension as per spec [5]

Extensions can be enabled and disabled with -mcpu using the same
syntax as with -march, and have same effect thats why it is
intrumented via TUNE_CCARGS_MARCH_OPTS

[1] https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#index-mcpu-2
[2] https://forums.raspberrypi.com/viewtopic.php?f=63&t=207888#p1332960
[3] https://github.com/llvm/llvm-project/issues/85699
[4] https://github.com/llvm/llvm-project/issues/90365
[5] https://developer.arm.com/documentation/109697/2025_06/Feature-descriptions/The-Armv9-0-architecture-extension

(From OE-Core rev: db1b355b2b15ba57bd89c2dfb88c2c667551863e)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Quentin Schulz <quentin.schulz@cherry.de>
Acked-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2025-08-04 18:04:03 +01:00
..
…

2012/03/30 - Mark Hatle <mark.hatle@windriver.com>
 - Initial Revision

The ARM architecture definitions are split among a number of files.
The primary definitions for the variables are handled by the core
arch-arm.inc file.

TUNE_ARCH is set to either "arm" or "armeb" depending on the value
of the existence of the "bigendian" feature in a given tune.

A small set of ARM specific variables have been defined to allow 
TUNE_PKGARCH to be automatically defined.  Optimized tunings must NOT 
change the definiton of TUNE_PKGARCH.  TUNE_PKGACH:tune-<tune> will be 
ignored.  The format of the package arch is enforced by the TUNE_PKGARCH
default.  The format must be of the form:
<armversion>[t][e][hf][b][-vfp][-neon]

TUNE_PKGARCH is defined as:
${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}

ARMPKGARCH - This is the core package arch component specified by each 
tuning.  This is the primary identifier of a tuning.  Usual values are:
arm, armv4, armv5, armv6, armv7a, etc.

ARMPKGSFX_THUMB - This is the thumb specific suffix.  Curently it is 
defined in feature-arm-thumb.inc.

ARMPKGSFX_DSP - This is the DSP specific suffix.  Currently this is set 
to 'e' when on armv5 and the dsp feature is enabled.

ARMPKGSFX_EABI - This is the eabi specific suffix.  There are currently 
two defined ABIs specificed, standard EABI and Hard Float (VFP) EABI.  
When the callconvention-hard is enabled, "hf" is specified, otherwise it 
is blank.

ARMPKGSFX_ENDIAN - This is the endian specific suffix.  It is defined in 
the core arch-arm.inc file.

ARMPKGSFX_FPU - This is the FPU specific suffix.  The suffix indicates 
specific FPU optimizations.  'vfp' and 'neon' are both defined.