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

[Carlos O'Donell <carlos at redhat dot com>]

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?

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?

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.

(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).

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.

Thoughts?

-- 
Cheers,
Carlos.