<div dir="ltr">The conversion of the synthetic section is now ongoing, so it might be a practical option to just wait for it to complete. If you cannot wait for it, I think I'm okay with this patch with TODO to remove it later. What do you think?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 1, 2016 at 6:58 AM, Peter Smith <span dir="ltr"><<a href="mailto:peter.smith@linaro.org" target="_blank">peter.smith@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've done a bit more research. It looks like even though the IRELATIVE<br>
relocations are in the .rel.plt the ifunc resolver is always called at<br>
startup and is not resolved at runtime. I don't know why this is the<br>
case, it may be that the number of IRELATIVE calls is sufficiently<br>
small that there isn't much overhead to just do it.<br>
<br>
>From some communication with the person that did the initial<br>
implementation for ARM it seems like there were two models of ifunc at<br>
the time, x86 which used .got.plt and PPC which used .got. ARM decided<br>
to follow the PPC model and AArch64 followed the x86 model. From<br>
memory the reasons for choosing the ppc model were:<br>
<br>
- Alan Modra's post on the PPC implementation:<br>
<a href="https://sourceware.org/ml/binutils/2009-07/msg00351.html" rel="noreferrer" target="_blank">https://sourceware.org/ml/<wbr>binutils/2009-07/msg00351.html</a><br>
- Conceptually it artifically divides the IRELATIVE uses for the<br>
.rel.plt from the IRELATIVE relocations in .rel.dyn for function<br>
pointers for local ifuncs that don't need PLT entries.<br>
- On some architectures such as Mips the .got.plt takes are a precious<br>
resource.<br>
<br>
One thing I'll need to check is if we handle function pointers<br>
correctly on x86 and aarch64.<br>
<br>
Peter<br>
<br>
On 31 October 2016 at 20:43, Rafael Espíndola<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
> On 31 October 2016 at 14:14, Peter Smith <<a href="mailto:peter.smith@linaro.org">peter.smith@linaro.org</a>> wrote:<br>
>> peter.smith added a comment.<br>
>><br>
>> On reflection I think that it could be possible to clean this up if the rel.dyn and rel.plt OutputSections are rewritten in terms of InputSections. The linker in Relocation.cpp would create the R_<TARGET>_IRELATIVE relocations in an InputSection called .rel.iplt or .rela.iplt. On targets such as AArch64 and X86 rela.iplt would be allocated to the .rela.plt OutputSection, on ARM and PPC (if the PPC lld Target supported it) would go into the .rel.dyn OutputSection.<br>
><br>
> I like this. It also solves the problem of putting the IRELATIVE<br>
> relocations after the other ones.<br>
><br>
> As for why other targets try to use .rela.plt, it is probably because<br>
> .rela.plt is processed lazily and .rela.dyn is not. Do you know if<br>
> there  is some ARM/PPC restriction that would force IRELATIVE to be<br>
> processed eagerly?<br>
><br>
> Cheers,<br>
> Rafael<br>
</div></div></blockquote></div><br></div>