<p dir="ltr">I was able to link and run the musl  dynamic linker with the patch that stops setting got[0].</p>
<p dir="ltr">So, Rui, what is your take on this? Should we leave that out of tree until it is time to try to link glibc's dynamic linker?</p>
<p dir="ltr">Cheers,<br>
Rafael</p>
<div class="gmail_quote">On May 9, 2016 10:50 AM, "H.J. Lu" <<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, May 9, 2016 at 7:39 AM, Rafael Espíndola<br>
<<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
> On 9 May 2016 at 10:20, H.J. Lu <<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>> wrote:<br>
>> On Mon, May 9, 2016 at 7:18 AM, Rafael Espíndola<br>
>> <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>>> On 9 May 2016 at 09:51, H.J. Lu <<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>> wrote:<br>
>>>> On Mon, May 9, 2016 at 6:47 AM, Rafael Espíndola<br>
>>>> <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>>>>>> Since the the link-time address of _DYNAMIC is stored in the first element<br>
>>>>>> of the GOT as specified by the x86-64 psABI, one can use<br>
>>>>>><br>
>>>>>> movq _GLOBAL_OFFSET_TABLE_(%rip), %rax<br>
>>>>>><br>
>>>>>> to get the link-time address of _DYNAMIC.<br>
>>>>><br>
>>>>> Given that this is being done before relocations, what is the<br>
>>>>> difference from just using _DYNAMIC?<br>
>>>><br>
>>>> It is the link-time address of _DYNAMIC vs the run-time address of<br>
>>>>  _DYNAMIC.<br>
>>><br>
>>><br>
>>> Do you know how it is used?<br>
>><br>
>>   /* Figure out the run-time load address of the dynamic linker itself.  */<br>
>>   bootstrap_map.l_addr = elf_machine_load_address ();<br>
>><br>
>> /* Return the link-time address of _DYNAMIC.  Conveniently, this is the<br>
>>    first element of the GOT.  This must be inlined in a function which<br>
>>    uses global data.  */<br>
>> static inline ElfW(Addr) __attribute__ ((unused))<br>
>> elf_machine_dynamic (void)<br>
>> {<br>
>>   /* This produces an IP-relative reloc which is resolved at link time. */<br>
>>   extern const ElfW(Addr) _GLOBAL_OFFSET_TABLE_[] attribute_hidden;<br>
>>   return _GLOBAL_OFFSET_TABLE_[0];<br>
>> }<br>
>><br>
>><br>
>> /* Return the run-time load address of the shared object.  */<br>
>> static inline ElfW(Addr) __attribute__ ((unused))<br>
>> elf_machine_load_address (void)<br>
>> {<br>
>>   /* Compute the difference between the runtime address of _DYNAMIC as seen<br>
>>      by an IP-relative reference, and the link-time address found in the<br>
>>      special unrelocated first GOT entry.  */<br>
>>   extern ElfW(Dyn) _DYNAMIC[] attribute_hidden;<br>
>>   return (ElfW(Addr)) &_DYNAMIC - elf_machine_dynamic ();<br>
>> }<br>
><br>
> OK, seems similar to what netbsd does. I am still not sure why. glibc<br>
> just seems to add back elf_machine_dynamic to read the dynamic table,<br>
> but it could do that without subtracting and adding<br>
> elf_machine_dynamic :-)<br>
<br>
Different targets have different implementations of elf_machine_load_address<br>
and elf_machine_dynamic.  The generic part of ld.so can't assume anything.<br>
Compiler will optimize it out on x86-64, which wasn't the case before<br>
<br>
commit 5f30cfec00f64edfc0ad932bf7065de13966b69d<br>
Author: H.J. Lu <<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>><br>
Date:   Sun Sep 2 05:22:24 2012 -0700<br>
<br>
    Use the first element of GOT for ld.so addresses<br>
<br>
      [BZ #14538]<br>
      * sysdeps/x86_64/dl-machine.h (elf_machine_dynamic): Use the<br>
      first element of the GOT.<br>
      (elf_machine_load_address): Return the difference between<br>
      the runtime address of _DYNAMIC and elf_machine_dynamic ().<br>
<br>
> In any case, I think this should be sufficient from lld's point of<br>
> view. I will update the patch to document and test it.<br>
><br>
><br>
>> Not going to work if a linker doesn't follow the psABI :-).<br>
><br>
> Sure, I would just be really surprised if this is all that is missing.<br>
><br>
> Cheers,<br>
> Rafael<br>
<br>
<br>
<br>
--<br>
H.J.<br>
</blockquote></div>