Hi Szabolcs,

Here is the C version one which should be portable in all cases.
aarch64 native glibc regression test checked Okay.

Regards,
Renlin

ChangeLog:

2017-10-18  Renlin Li  <renlin.li@arm.com>

	* sysdeps/aarch64/dl-machine.h (elf_machine_load_address): Use
	_DYNAMIC symbol to calculate load address.


On 17/10/17 17:28, Szabolcs Nagy wrote:
> On 17/10/17 16:41, Szabolcs Nagy wrote:
>> On 04/11/16 09:42, Renlin Li wrote:
>>> Hi all,
>>>
>>> This patch rewrites aarch64 elf_machine_load_address to use special _DYNAMIC
>>> symbol instead of _dl_start.
>>>
>>> The static address of _DYNAMIC symbol is stored in the first GOT entry.
>>> Here is the change which makes this solution work.
>>> https://sourceware.org/ml/binutils/2013-06/msg00248.html
>>>
>>> i386, x86_64 targets use the same method to do this as well.
>>>
>>> The original implementation relies on a trick that R_AARCH64_ABS32 relocation
>>> being resolved at link time and the static address fits in the 32bits.
>>> However, in LP64, normally, the address is defined to be 64 bit.
>>>
>>> Additionally, the original inline assembly is not optimized. It uses 4
>>> instructions including a jump.
>>>
>>> Optimally, the new implementation here is just two instructions:
>>> ldr %1, _GLOBAL_OFFSET_TABLE_
>>> adr %2, _DYNAMIC
>>>
>>> The size of ld.so is around 130K, so it's save to use ldr, adr to get the address.
>>> The address range for those two instruction is +/-1MB.
>>>
>>> And by the way, this method is ILP32 safe as well.
>>> aarch64 linux toolchain regression test OK. OK to commit?
>>>
>>> Regards,
>>> Renlin Li
>>>
>>>
>>> ChangeLog:
>>>
>>> 2016-11-04  Renlin Li  <renlin.li@arm.com>
>>>
>>>      * sysdeps/aarch64/dl-machine.h (elf_machine_load_address): Use
>>>      _DYNAMIC symbol to calculate load address.
>>
>> This is OK.
>>
>> (Roland notes that introducing a BASE symbol with a
>> linker script would even avoid loading GOT[0], but
>> that can be done separately across targets)
>>
>
> please wait with this.
>
> looking at the static pie patches, it seems that also needs
> to compute the base address and that cannot assume -mcmodel=tiny,
> i don't remember if there was a particular reason -mcmodel=large
> would be problematic, if inline asm was only used to save a
> few instructions then please resend the patch but using c code
> (like what x86_64 is doing), that's less fragile.
>