Re: [PATCH] x86: Generate PLT relocations for -z now

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, May 11, 2017 at 10:33 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 05/11/2017 01:09 PM, H.J. Lu wrote:
>> On Thu, May 11, 2017 at 9:44 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> On 05/11/2017 10:51 AM, H.J. Lu wrote:
>>>> The run-time R_X86_64_GLOB_DAT relocation against foo is
>>>> required.  There is no need to add another run-time
>>>> R_X86_64_JUMP_SLOT relocation.  We can add a linker option
>>>> to generate the extra R_X86_64_JUMP_SLOT.  But I don't think
>>>> it should be the default.
>>>
>>> I don't disagree with your analysis, I disagree with the execution
>>> of the plan.
>>>
>>> The plan should be:
>>>
>>> (a) Analyze uses of the PLT entries.
>>>
>>> In this case LD_AUDIT, LD_PROFILE, and ltrace all require them to
>>> operate correctly.
>>
>> As I stated before, glibc and GCC have been doing everything we
>> can to avoid PLT.
>>
>>> (b) Develop plan for migrating developer tooling, like LD_AUDIT,
>>>     which is a part of glibc and is well supported.
>>>
>>> (c) Choose one of:
>>>
>>>     (C.1) Make PLT elision optional e.g. -z noplt
>>>
>>>     or
>>>
>>>     (C.2) Make LD_AUDIT work with optimizations.
>>
>> This is the only option.
>
> Why is this the only option?
>
> Is it the only option because we want to reduce the number of dynamic
> relocs as much as possible?
>

Yes and a function can be called via GOT.

> Is it because we have benchmarks that show reducing relocations helps
> some application?
>
> Or is it an abstract engineering decision that a minimum number of
> relocations is always a good thing? Even though their cost might be
> hidden in subsequent load/store latencies?

What did you mean by hidden cost?

> If (C.2) is truly the only option, then what are our solutions?
>
> (a) Always generate the PLT entries, even if they might be unused.

That is not "Make LD_AUDIT work with optimizations."

> (b) If LD_AUDIT is in effect resolve all R_X86_64_GLOB_DAT which
>     would otherwise have resolved to an STT_FUNC (or equivalent)
>     to the appropriate PLT entry for the function in question.
>     This would bind all such functions to run the profiled resolution
>     function for the lifetime of the process because potentially with
>     -z now, and -z relro this decision is binding
>     once made (and the GOT entries relocated).

This also works with functions called via function pointer.

> In (b) how do we find which PLT entry (index) to use for which GOT
> entry? If we had a 1:1 correspondence then we could make the mapping
> work.

ld.so may need to create PLT on the fly for each GLOB_DAT relocation
against function and use its PLT entry as function address.

-- 
H.J.