feat(azurelinux-rpm-config): set x86_64 cpu level to v2

[ddstreet]

Replace the logic that sets the x86_64 cpu level to either v2 or v3
depending on the RHEL release, to hardcoding it to v2, as we consider
v2 to be our baseline for supported hardware, and we do not plan to
support (or function on) older x86_64 v1 hardware.

Fixes: AB#20423

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Sets x86_64-v2 as Azure Linux’s fixed minimum CPU baseline.

Changes:

• Overrides the upstream architecture-level macro.
• Refreshes generated spec metadata and component lock data.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

File	Description
base/comps/azurelinux-rpm-config/azurelinux-rpm-config.comp.toml	Adds the CPU-level overlay.
specs/a/azurelinux-rpm-config/macros	Applies the x86_64-v2 baseline.
specs/a/azurelinux-rpm-config/azurelinux-rpm-config.spec	Updates generated release metadata.
locks/azurelinux-rpm-config.lock	Refreshes the input fingerprint.

[github-actions]

🔒❌ Lock files are out of date

FIX: — run this and commit the result:

azldev component update -p azurelinux-rpm-config

Or download the fix patch and apply it:

gh run download 29550962797 -R microsoft/azurelinux -n locks-patch
git apply locks.patch

Changed components (1)

Component	New upstream commit
azurelinux-rpm-config	6e4185bb29f2ca019b36bec8006e7ad60e58cade

[ddstreet]

Note that this only sets the -march= parameter to use the x86_64-v2 ISA target; this does not remove the -mtune parameter which remains set to generic. The result is a binary which uses the x86_64-v2 instruction set, but doesn't require it (i.e. it should still run on x86_64-v1 hardware). Specifically:

$ readelf -j .note.gnu.property usr/bin/bash

Displaying notes found in: .note.gnu.property
  Owner                Data size        Description
  GNU                  0x00000040       NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature: IBT, SHSTK
        x86 ISA needed: x86-64-baseline
        x86 feature used: x86, XMM
        x86 ISA used: x86-64-baseline, x86-64-v2

I'm not a compiler expert, but my assumption is that gcc is generating multiple optimized code paths, that use the x86_64-v2 ISA if available (which it always will be) but also has code paths that will work for older x86_64-v1 ISA hardware - and presumably those code paths will never be used, and only serve to (slightly?) increase the binary file size. That's IIUC of course, and I certainly could be wrong.

I did check RHEL 10.1, since that definitely does build specifically for x86_64-v3, and their binaries do actually require the x86_64-v3 ISA, e.g.:

$ readelf -n /bin/bash

Displaying notes found in: .note.gnu.property
  Owner                Data size 	Description
  GNU                  0x00000040	NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature: IBT, SHSTK
	x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64-v3
	x86 feature used: x86, XMM, YMM
	x86 ISA used: x86-64-baseline, x86-64-v3

Maybe we need to also adjust/remove the -mtune=generic from the %__cflags_arch_x86_64_common macro?

[christopherco]

That's definitely interesting. Was glibc also rebuilt with -march=x86-64-v2 in the build chroot prior to building bash with -march=x86-64-v2?

Looks like the ISA Needed ELF note in the final binary is an OR of the ISA Needed property (GNU_PROPERTY_X86_ISA_1_NEEDED) of each of the relocatable object inputs. glibc emits a value for GNU_PROPERTY_X86_ISA_1_NEEDED in its crt1.o/Scrt1.o. If glibc was not rebuilt with -march=x86-64-v2, crt1.o/Scrt1.o from glibc has the GNU_PROPERTY_X86_ISA_1_NEEDED property still set to baseline v1 only. Additionally we likely don't emit GNU_PROPERTY_X86_ISA_1_NEEDED in any of bash's gcc-generated objects because we don't specify -mneeded during their gcc build (which we likely shouldn't do). So the linker OR-ing them together, that could explain why bash reports only v1 baseline as needed and no v2.

[ddstreet]

Yep that was it, glibc rebuilds with ISA needed set to x86_64-v2, and with that bash also has ISA needed as -v2, so it should be all good once we mass-rebuild (with an already-rebuilt glibc and other libs).

[Copilot]

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

[reubeno]

Change looks righteous to me.

Do we also have an aarch64 CPU level change in the works (in parallel)? Don't quote me on it, but aarch64 SKUs in Azure seem to be armv8.2 (the Ampere ones) or armv9 (Cobalt 100+)?

[ddstreet]

Change looks righteous to me.

Do we also have an aarch64 CPU level change in the works (in parallel)? Don't quote me on it, but aarch64 SKUs in Azure seem to be armv8.2 (the Ampere ones) or armv9 (Cobalt 100+)?

I'll defer to @christopherco on that? I am not aware of any open bug for aarch64...

[christopherco]

Change looks righteous to me.
Do we also have an aarch64 CPU level change in the works (in parallel)? Don't quote me on it, but aarch64 SKUs in Azure seem to be armv8.2 (the Ampere ones) or armv9 (Cobalt 100+)?

I'll defer to @christopherco on that? I am not aware of any open bug for aarch64...

We do not. There was some waffling on the exact ARM hardware to target, so baseline ARMv8 is what we had originally landed on.

[christopherco]

Changes themselves LGTM. One optional style nit-pick.
Requesting changes to squash the commits together into one commit, which should also get the CI checks passing

[christopherco]

nit (style): Add a comment above this or include a description field in the overlay itself.