MDEV-35566 Ensure compatibility with ARMv9 by updating .arch directive

[cythe]

The pmem_cvap() function currently uses the '.arch armv8.2-a' directive for the 'dc cvap' instruction. This will cause build errors below when compiling for ARMv9 systems. Update the '.arch' directive to 'armv9.4-a' to ensure compatibility with ARMv9 architectures.

{standard input}: Assembler messages:
{standard input}:169: Error: selected processor does not support retaa' {standard input}:286: Error: selected processor does not support retaa' make[2]: *** [storage/innobase/CMakeFiles/innobase_embedded.dir/build.make: 1644: storage/innobase/CMakeFiles/innobase_embedded.dir/sync/cache.cc.o] Error 1

• The Jira issue number for this PR is: MDEV-35566

Description

The pmem_cvap() function currently uses the '.arch armv8.2-a' directive
for the 'dc cvap' instruction. This will cause build errors below when
compiling for ARMv9 systems. Update the '.arch' directive to 'armv9.4-a'
to ensure compatibility with ARMv9 architectures.

{standard input}: Assembler messages:
{standard input}:169: Error: selected processor does not support retaa' {standard input}:286: Error: selected processor does not support retaa'
make[2]: *** [storage/innobase/CMakeFiles/innobase_embedded.dir/build.make:
1644: storage/innobase/CMakeFiles/innobase_embedded.dir/sync/cache.cc.o]
Error 1

Release Notes

TODO: What should the release notes say about this change?
Include any changed system variables, status variables or behaviour. Optionally list any https://mariadb.com/kb/ pages that need changing.

How can this PR be tested?

TODO: modify the automated test suite to verify that the PR causes MariaDB to behave as intended.
Consult the documentation on "Writing good test cases".

If the changes are not amenable to automated testing, please explain why not and carefully describe how to test manually.

Basing the PR against the correct MariaDB version

• This is a new feature or a refactoring, and the PR is based against the main branch.
• This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ cythe
❌ dr-m
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[dr-m]

I just now realized that this addresses the comments that I made in #3675. It would have been clearer to update #3675 instead of filing this one.

As far as I understand, we still have not set up a build environment where this problem could be reproduced.

[ggardet]

Hi. This PR has been merged to 10.11 tree, but I think it should be merged to main and 11.x as well.

[svoj]

@ggardet it will be merged to 11.x eventually.

[ggardet]

I wonder why you used .arch armv9.4-a and not .arch armv9.0-a?

[lumag]

@cythe this still fails to build on (for example) for ARMv8.6-a (well, in fact, any ARMv8.3-a+). If the build is configured with -march=armv8.6-a+crypto -mbranch-protection=standard -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security flags, then the build still fails with:

Assembler messages:
{standard input}:169: Error: selected processor does not support `retaa'
{standard input}:271: Error: selected processor does not support `retaa'

This happens because although GCC inserts the .arch clause at the top of the file, the pmem_cvap manually inserts .arch armv8-2.a clause, which makes GAS forbid the retaa instruction.

[grooverdan]

@cythe this still fails to build on (for example) for ARMv8.6-a (well, in fact, any ARMv8.3-a+). If the build is configured with -march=armv8.6-a+crypto -mbranch-protection=standard -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security flags, then the build still fails with:

Assembler messages:
{standard input}:169: Error: selected processor does not support `retaa'
{standard input}:271: Error: selected processor does not support `retaa'

This happens because although GCC inserts the .arch clause at the top of the file, the pmem_cvap manually inserts .arch armv8-2.a clause, which makes GAS forbid the retaa instruction.

@lumag are you able to provide a corrected implementation in a new PR please?

[lumag]

This happens because although GCC inserts the .arch clause at the top of the file, the pmem_cvap manually inserts .arch armv8-2.a clause, which makes GAS forbid the retaa instruction.

@lumag are you able to provide a corrected implementation in a new PR please?

That would require a lot of troubles with the CLA and also internal handling of the contributions, sorry.

I can point out to the patch that makes it work for our configuration: https://lore.kernel.org/openembedded-devel/20260520113418.2523208-1-dmitry.baryshkov@oss.qualcomm.com/

[grooverdan]

ack. Thank you. I'll prepare a submission base on that.

A BSD-new contribution option instead of a CLA isn't sufficient?