[PATCH] D26029: [LLD][ARM] ARM IRELATIVE relocations are in rel.dyn

Peter Smith via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 2 02:38:48 PDT 2016


I've got a few fixes that need to go in to fix static linking on ARM,
ifunc is the first of them. What I suggest is that I post the others
first and see where we are with synthetic sections at that point.

Patches incoming:
- Static TLS fixes
- ARM and AArch64 weak reference handling

These are independent of the ifunc patch.



On 2 November 2016 at 01:12, Rui Ueyama <ruiu at google.com> wrote:
> 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?
>
> On Tue, Nov 1, 2016 at 6:58 AM, Peter Smith <peter.smith at linaro.org> wrote:
>>
>> I've done a bit more research. It looks like even though the IRELATIVE
>> relocations are in the .rel.plt the ifunc resolver is always called at
>> startup and is not resolved at runtime. I don't know why this is the
>> case, it may be that the number of IRELATIVE calls is sufficiently
>> small that there isn't much overhead to just do it.
>>
>> From some communication with the person that did the initial
>> implementation for ARM it seems like there were two models of ifunc at
>> the time, x86 which used .got.plt and PPC which used .got. ARM decided
>> to follow the PPC model and AArch64 followed the x86 model. From
>> memory the reasons for choosing the ppc model were:
>>
>> - Alan Modra's post on the PPC implementation:
>> https://sourceware.org/ml/binutils/2009-07/msg00351.html
>> - Conceptually it artifically divides the IRELATIVE uses for the
>> .rel.plt from the IRELATIVE relocations in .rel.dyn for function
>> pointers for local ifuncs that don't need PLT entries.
>> - On some architectures such as Mips the .got.plt takes are a precious
>> resource.
>>
>> One thing I'll need to check is if we handle function pointers
>> correctly on x86 and aarch64.
>>
>> Peter
>>
>> On 31 October 2016 at 20:43, Rafael EspĂ­ndola
>> <rafael.espindola at gmail.com> wrote:
>> > On 31 October 2016 at 14:14, Peter Smith <peter.smith at linaro.org> wrote:
>> >> peter.smith added a comment.
>> >>
>> >> 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.
>> >
>> > I like this. It also solves the problem of putting the IRELATIVE
>> > relocations after the other ones.
>> >
>> > As for why other targets try to use .rela.plt, it is probably because
>> > .rela.plt is processed lazily and .rela.dyn is not. Do you know if
>> > there  is some ARM/PPC restriction that would force IRELATIVE to be
>> > processed eagerly?
>> >
>> > Cheers,
>> > Rafael
>
>


More information about the llvm-commits mailing list