Re: [GLIBC][AARCH64]Rewrite elf_machine_load_address using _DYNAMIC symbol

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

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.