bsd.cpu.mk: Add a workaround for erratum 843419

[andrew]

Summary

Add a workaround for the Arm Cortex-A53 erratum 843419. This has been
targeted when the build is either unoptimised for any CPU/architecture
or targets the Cortex-A53 or ARMv8.0 architecture.

PR: 296240
PR: 296395
Sponsored by: Arm Ltd

[bz]

I think the only thing I'd love to see is to tell users in the commit message how to apply this as it seems this needs to be done manually.

The other question I have: does this work with gcc or do we need -mfix-cortex-a53-843419 there?

[mmel]

In D58212#1335515, @bz wrote:

I think the only thing I'd love to see is to tell users in the commit message how to apply this as it seems this needs to be done manually.

The fixup is applied automatically if your CPUTYPE is set to 'generic', 'armv8-a', 'cortex-a53' or if it is left empty.

The other question I have: does this work with gcc or do we need -mfix-cortex-a53-843419 there?

Yes, the linker flag is compatible with the GCC toolchain/linker.

Sure, enabling the -mfix-cortex-a53-843419 flag in clang also for FreeBSD will make things much cleaner. It's hard to say why it's not enabled yet.
Then enable all Cortex mitigations unconditionally (there are three others) and then leave all this dance to the compiler.

[andrew]

In D58212#1335516, @mmel wrote:

In D58212#1335515, @bz wrote:

I think the only thing I'd love to see is to tell users in the commit message how to apply this as it seems this needs to be done manually.

The fixup is applied automatically if your CPUTYPE is set to 'generic', 'armv8-a', 'cortex-a53' or if it is left empty.

It should also be applied to a CPUTYPE of cortex-a57.cortex-a53.

The world will need to be rebuilt, however as a limited number of cores are affected, and it seems difficult to hit the erratum I'm not planning on forcing a rebuild for everyone.

[markmi_dsl-only.net]

This is apparently making some port-package build fail with:

"ld.lld: error: --fix-cortex-a53-843419 is only supported on AArch64"

An example on ampere2 is:

amd64-rust-bootstrap-1.97.1 lang/rust-bootstrap@amd64 build 0 ??? 06:35:04

https://pkg-status.freebsd.org/ampere2/data/main-arm64-default/pb5533b53ae5e_s297394e995e/logs/errors/amd64-rust-bootstrap-1.97.1.log

Quoting:
. . .

It fails with the following output:

  Change Dir: '/wrkdirs/usr/ports/lang/rust-bootstrap/work-amd64/_build/x86_64-unknown-freebsd/llvm/build/CMakeFiles/CMakeScratch/TryCompile-N8ubzl'
  
  Run Build Command(s): /usr/local/bin/ninja -v cmTC_e0e9e
  [ 50% 1/2] /usr/local/freebsd-sysroot/amd64/bin/cc   -ffunction-sections -fdata-sections -fPIC -m64 --target=x86_64-unknown-freebsd -pipe -fstack-protector-strong -fno-strict-aliasing -MD -MT CMakeFiles/cmTC_e0e9e.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_e0e9e.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_e0e9e.dir/testCCompiler.c.o -c /wrkdirs/usr/ports/lang/rust-bootstrap/work-amd64/_build/x86_64-unknown-freebsd/llvm/build/CMakeFiles/CMakeScratch/TryCompile-N8ubzl/testCCompiler.c
  [100% 2/2] : && /usr/local/freebsd-sysroot/amd64/bin/cc -ffunction-sections -fdata-sections -fPIC -m64 --target=x86_64-unknown-freebsd -pipe -fstack-protector-strong -fno-strict-aliasing -lz  -Wl,--fix-cortex-a53-843419 CMakeFiles/cmTC_e0e9e.dir/testCCompiler.c.o -o cmTC_e0e9e   && :
  FAILED: [code=1] cmTC_e0e9e 
  : && /usr/local/freebsd-sysroot/amd64/bin/cc -ffunction-sections -fdata-sections -fPIC -m64 --target=x86_64-unknown-freebsd -pipe -fstack-protector-strong -fno-strict-aliasing -lz  -Wl,--fix-cortex-a53-843419 CMakeFiles/cmTC_e0e9e.dir/testCCompiler.c.o -o cmTC_e0e9e   && :
  ld.lld: error: --fix-cortex-a53-843419 is only supported on AArch64
  cc: error: linker command failed with exit code 1 (use -v to see invocation)
  ninja: build stopped: subcommand failed.

[markmi_dsl-only.net]

As I understand it, 14.5-RELEASE is based on llvm21 and, so, will likely have the aarch64 erratum 843419 problem as stands.

But the tradeoff vs. build failures for the likes of amd64-rust-bootstrap-1.97.1 lang/rust-bootstrap@amd64 on aarch64 for this specific fix might not be obvious.

So I just note that 14.5-RELEASE may want to have this aarch64 erratum 843419 handling if the tradeoff is okay.