Fix compilation on early arm architectures

[Harry-Chen]

Motivation and Context

Currently OpenZFS won't build on early arm architectures (see debian port on armel).

Some errors are generated when compiling module/icp/asm-arm/sha2/sha256-armv7.S and module/icp/asm-arm/sha2/sha512-armv7.S:

module/icp/asm-arm/sha2/sha256-armv7.S: Assembler messages:
module/icp/asm-arm/sha2/sha256-armv7.S:92: Error: selected processor does not support `rev r2,r2' in ARM mode
module/icp/asm-arm/sha2/sha256-armv7.S:150: Error: selected processor does not support `rev r2,r2' in ARM mode
module/icp/asm-arm/sha2/sha256-armv7.S:208: Error: selected processor does not support `rev r2,r2' in ARM mode
module/icp/asm-arm/sha2/sha256-armv7.S:266: Error: selected processor does not support `rev r2,r2' in ARM mode
...

module/icp/asm-arm/sha2/sha512-armv7.S: Assembler messages:
module/icp/asm-arm/sha2/sha512-armv7.S:168: Error: selected processor does not support `rev r3,r3' in ARM mode
module/icp/asm-arm/sha2/sha512-armv7.S:169: Error: selected processor does not support `rev r4,r4' in ARM mode

But the code actually has compiler guards to provide support for early arm architectures:

zfs/module/icp/asm-arm/sha2/sha256-armv7.S

Lines 83 to 108 in a94860a

	#if __ARM_ARCH__>=7
	@ ldr r2,[r1],#4 @ 0
	# if 0==15
	str r1,[sp,#17*4] @ make room for r1
	# endif
	eor r0,r8,r8,ror#5
	add r4,r4,r12 @ h+=Maj(a,b,c) from the past
	eor r0,r0,r8,ror#19 @ Sigma1(e)
	# ifndef __ARMEB__
	rev r2,r2
	# endif
	#else
	@ ldrb r2,[r1,#3] @ 0
	add r4,r4,r12 @ h+=Maj(a,b,c) from the past
	ldrb r12,[r1,#2]
	ldrb r0,[r1,#1]
	orr r2,r2,r12,lsl#8
	ldrb r12,[r1],#4
	orr r2,r2,r0,lsl#16
	# if 0==15
	str r1,[sp,#17*4] @ make room for r1
	# endif
	eor r0,r8,r8,ror#5
	orr r2,r2,r12,lsl#24
	eor r0,r0,r8,ror#19 @ Sigma1(e)
	#endif

Also, another error would be thrown when __ARM_ARCH__ macro is correctly set with early arms:

$ arm-linux-gnueabihf-gcc -march=armv6 -msoft-float -c sha256-armv7.S -o sha256-armv7.o
sha256-armv7.S: Assembler messages:
sha256-armv7.S:1853: Error: invalid constant (ffffffffffffefa0) after fixup

This is caused by adr instruction on L1849:

zfs/module/icp/asm-arm/sha2/sha256-armv7.S

Lines 1845 to 1853 in a94860a

	.LNEON:
	stmdb sp!,{r4-r12,lr}
	sub r11,sp,#16*4+16
	adr r14,K256
	bic r11,r11,#15 @ align for 128-bit stores
	mov r12,sp
	mov sp,r11 @ alloca
	add r2,r1,r2,lsl#6 @ len to point at the end of inp

On early ISAs, adr could not load an address (K256) that is too far away from PC.

Description

1. Use __ARM_ARCH that would be set by compiler (both GCC and Clang) when possible, so that these files compile with early architectures such as armv5te and armv6.
2. Replace adr with ldr on early architectures.

How Has This Been Tested?

The code now compiles on armv5te and armv6. Since I have made no functionality change and it is taken from OpenSSL, I suppose no further test is needed.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[happyaron]

This PR is applied in Debian to fix compilation of the armel architecture, which unfortunately has a baseline of armv5te.

[behlendorf]

Looks good to me. Thanks for resolving this issue.

[Harry-Chen]

@behlendorf Thanks for your review! However my PR contained two commits that solves two issues on arm, I see only f9afa21 merged but bd7b0a7 not. Is this expected?

[Harry-Chen]

@behlendorf Thanks for your review! However my PR contained two commits that solves two issues on arm, I see only f9afa21 merged but bd7b0a7 not. Is this expected?

I just found that both two are merged. It turned out to be my carelessness. Just ignore this :-)

[behlendorf]

No worries. I see that one of the commits 4340f69 wasn't automatically linked to this PR. I'm not sure why not.