Work around incompatibility with ancient GNU as (GNU binutils)

[briansmith]

We have multiple bug reports where the latest release of ring doesn't build when using old versions of GNU binutils:

• ring-0.17.13 build failure on amazonlinux:2 amd64 #2462
• ring 0.17.13 does not "cross" compile (on illumos, other x86_64 targets) unlike ring 0.17.12 #2461

Luckily, this isn't urgent as ring 0.17.12 is available for people to use, but it could become urgent at any time if we have a security fix because we only do security releases on top of the latest version.

There are multiple workarounds available:

• Upgrade GNU binutils to a later version (2.38 seems sufficient; maybe some earlier versions work?)
• Use CC=clang or TARGET_CC=clang or similar, to use clang and llvm-as instead of GNU as.

I think somebody needs to investigate exactly why GNU as 2.29 rejects the instruction, to see if we can find an easy workaround. I don't have access to GNU as older than 2.38.

Perhaps there is an easy workaround, such as adding an .arch directive to aes-gcm-avx2-x86_64.pl that would make it work.

Or, there could be more tedious workarounds. In OpenSSL, in the past at least, they have sometimes used .byte directives to directly encode instructions. For example, for mulx in x86_64-mont.pl we have:

.byte	0xc4,0x62,0xfb,0xf6,0xa1,0x10,0x00,0x00,0x00	# mulx	2*8($nptr),%rax,%r12

The difficulty here, of course, is that the registers being accessed are encoded into the instruction, so this is kind of a last resort workaround.

I don't intend to implement such a workaround myself, but others might be interested in doing so.

[briansmith]

I think the first step might be to investigate why BoringSSL doesn't try to work around it. Maybe they are building the assembly code with different options than we are, in which case we might be able to just do what they're doing. I didn't see anything to that effect when I looked though.

[briansmith]

Copying from what I wrote in #2461 so people understand the exact incompatibility:

According to the log above, these (using XMM registers) are accepted by the assembler:

	vpclmulqdq	$0x00,%xmm3,%xmm3,%xmm0
	vpclmulqdq	$0x01,%xmm3,%xmm3,%xmm1
	vpclmulqdq	$0x10,%xmm3,%xmm3,%xmm2

	vpclmulqdq	$0x01,%xmm0,%xmm6,%xmm2

	vpclmulqdq	$0x11,%xmm3,%xmm3,%xmm5
	vpclmulqdq	$0x01,%xmm1,%xmm6,%xmm0

But these are not:

	vpclmulqdq	$0x00,%ymm5,%ymm3,%ymm0
	vpclmulqdq	$0x01,%ymm5,%ymm3,%ymm1
	vpclmulqdq	$0x10,%ymm5,%ymm3,%ymm2

	vpclmulqdq	$0x01,%ymm0,%ymm6,%ymm2

	vpclmulqdq	$0x11,%ymm5,%ymm3,%ymm4
	vpclmulqdq	$0x01,%ymm1,%ymm6,%ymm0

So the issue is that the old as doesn't accept the use of YMM registers with vpclmulqdq.

Also, I think that because the version of binutils is so old, it falls outside of Google's toolchain compatibility policy, so I bet they aren't too interested in this.

[briansmith]

Good news: cross-rs is being updated with new binutils; see cross-rs/cross#1639.

[briansmith]

Eric Biggers mentioned that VPCLMULQDQ support was added in binutils version 2.30 (released in January 2018). So potentially any binutils version less than 2.30 will be too old to compile ring for x86_64.

[briansmith]

Ubuntu 18.04 and later have binutils >= 2.30 (According to https://launchpad.net/ubuntu/bionic/+source/binutils).

CentOS/RHEL/etc. 7 and later have binutils >= 2.30. CentOS 6 seems to have 2.20, which is too old.

Amazon Linux 2 has 2.29.1 as its default binutils version, which is too old, but @wez noted in #2462 (comment) that gcc10 works on Amazon Linux 2:

I did confirm just now that installing:

• gcc10-binutils
• gcc10

Allows running CC=gcc10-cc cargo check for the current state of main in the ring repo.

Amazon Linux 2023 seems to have a new-enough binutils.

If you are using cross-rs/corss to target x86_64-unknown-linux-*, you may have to use a pre-release image instead of the latest release (2.5). v2.5 was released in 2023. Something like this in Cross.toml:

[target.x86_64-unknown-gnu]
image = "ghcr.io/cross-rs/x86_64-unknown-linux-gnu:$something"
[]

Where $something is an OCI image tag. main will work as the tag, but the main tag seems to track the main branch of the cross-rs/cross repository, so using main probably isn't the best choice. See cross-rs/cross#1639 and cross-rs/cross#1641.