`__aeabi_uread4` and `__aeabi_uread8` should take a pointer to const

[tgross35]

At

abi-aa/rtabi32/rtabi32.rst

Lines 1421 to 1424 in 2b21824

	int __aeabi_uread4(void *address);
	int __aeabi_uwrite4(int value, void *address);
	long long __aeabi_uread8(void *address);
	long long __aeabi_uwrite8(long long value, void *address);

these are defined as:

int __aeabi_uread4(void *address);
int __aeabi_uwrite4(int value, void *address);
long long __aeabi_uread8(void *address);
long long __aeabi_uwrite8(long long value, void *address);

but there shouldn't be any reason for the read variants to need to write the pointer. Could it be updated to const void *address?

[smithp35]

but there shouldn't be any reason for the read variants to need to write the pointer. Could it be updated to const void *address?

I had a look through the archives to see if there was anything recorded about the decision. Only mention I can find is that the prototype prior to the ABI (Arm's proprietary compiler) was __packed int* which was changed to void * to avoid a proprietary extension.

To the best of my knowledge I think it could probably be updated without breaking any known implementation, however I'm reluctant to do so unless there's a particularly good reason to change it. I expect that it would be safer to introduce new functions with a const void* parameter rather change an existing API. These could be aliases of existing functions.

However this is adding costs to implementers, that I'm not sure is worth it. These functions are rarely used as a lot of Arm hardware can do unaligned accesses in hardware, and it is often better to inline the code to do the accesses than use a function anyway.

[tgross35]

I asked about changing this now because the intrinsic is likely going to become more popular pretty soon, the LLVM version released a few weeks ago emits it with size-optimized binaries. It's probably just legacy carryover to not have the const, but IMO this may as well be fixed: anybody calling directly (even just in tests) would benefit from not needing to forge non-const-ness, and an implementation that writes to the pointer could probably cause runtime bugs anyway.

For a spot check, two popular implementations wouldn't have an issue with const https://github.com/llvm/llvm-project/blob/bbd998f0186f5362d3c9c1cc575bf6ce20007685/compiler-rt/lib/builtins/arm/aeabi_uread4.S https://github.com/gcc-mirror/gcc/blob/be2bf2db773c01516b71a388221d61443fa069ee/libgcc/config/arm/unaligned-funcs.c#L25-L57 (I don't see an implementation in optimized-routines).

[smithp35]

I can run it past my GNU colleagues, as it would need their agreement to change. Arm's proprietary toolchain implementation (assembly), where these originated from, is also fine.