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

[Carlos O'Donell <carlos@redhat.com>]

On 05/09/2017 10:55 AM, Szabolcs Nagy wrote:
> On 09/05/17 15:24, Carlos O'Donell wrote:
>> On 05/08/2017 04:21 PM, H.J. Lu wrote:
>>>
>>> This patch partially reverses:
>>>
>>> commit 25070364b0ce33eed46aa5d78ebebbec6accec7e
>>> Author: H.J. Lu <hjl.tools@gmail.com>
>>> Date:   Sat May 16 07:00:21 2015 -0700
>>>
>>>     Don't generate PLT relocations for now binding
>>>
>>> to support LD_AUDIT and LD_PROFILE with -z now.  If there is an existing
>>> GOT relocation, it is still used to avoid PLT relocation against the same
>>> function symbol.
>>>
>>> Any comments?
>> I'm testing this on x86_64 locally to make sure it meets the needs of the
>> Fedora and Red Hat users that are actively making use of LD_AUDIT.
>>
>> Thanks for looking into this and supporting developer tooling that works
>> in binutils 2.25, but broke in 2.26 and onwards.
>>
> 
> i don't think plt should be considered to be part of the dso abi,
> so removing plt relocs should be safe (making a GOT-indirect call
> is a valid optimization, since plt is only there for lazy binding
> which is an optimization too, gcc can change plt relocs to noplt
> ones without -fno-plt so relying on it was never safe).

We have support for LD_AUDIT and LD_PROFILE, along with ltrace tooling,
all of which rely on the PLT entries.

We need to consider the consequences of these changes on the developer
tooling before jumping into such decisions.

> Alexander Monakov pointed out to me that ld audit could be fixed
> in principle to work with GOT-indirect calls e.g. by generating
> its entry point trampolines on the fly.

This is exactly the kind of consideration we should be making _before_
we checkin changes that break existing developer tooling that we support.

We need not consider this a public ABI aspect, but like we do for ASAN
and other tooling we need to consider how glibc changes impact all
developers.

Underneath the hood all of the toolcain and the developer tooling are
working in unison to try deliver something that works.

-- 
Cheers,
Carlos.