From commit 79e741920446582bd0e09f3e2b9f899c258efa56
R_AARCH64_ABS64 under LP64 is allowed in shared object and a dynamic relocation entry
will be generated. This allows the dynamic linker to do further symbol resolution.
R_AARCH64_ABS32 likewise is allowed in shared object, however under ILP32 abi.
The original behavior for R_AARCH64_ABS32 under LP64 is that, it's allowed
in shared object and silently resolved at static linking time.
No dynamic relocation entry is generate for it.
One could argue that absolute relocations against *absolute* ELF symbols should always be resolved at static link time, but I am aware that, for historical reasons, symbols like __GLOBAL_OFFSET_TABLE__ are emitted as absolute, making this difficult to realise in practice.
From commit 79e741920446582 bd0e09f3e2b9f89 9c258efa56
R_AARCH64_ABS64 under LP64 is allowed in shared object and a dynamic relocation entry
will be generated. This allows the dynamic linker to do further symbol resolution.
R_AARCH64_ABS32 likewise is allowed in shared object, however under ILP32 abi.
The original behavior for R_AARCH64_ABS32 under LP64 is that, it's allowed
in shared object and silently resolved at static linking time.
No dynamic relocation entry is generate for it.
One could argue that absolute relocations against *absolute* ELF symbols should always be resolved at static link time, but I am aware that, for historical reasons, symbols like __GLOBAL_ OFFSET_ TABLE__ are emitted as absolute, making this difficult to realise in practice.