This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 11/05/17 04:44, 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 <>
>> 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?
> Thank you very much for looking at this.
> This is definitely a positive step forward. And it passes all the tests
> I had locally for validation. It is not yet complete though. As you note,
> there are still cases where this breaks LD_AUDIT and such cases can happen
> in real code.
> Your example:
> extern void foo (void);
> void *
> foo_p ()
> {
>   foo ();
>   return foo;
> }
> Is one such case, where no PLT entry for foo is generated and we can't
> audit foo. There is no workaround for this except to patch binutils.

i think this is not a binutils issue,
gcc can do an optimization to load
foo from the got and call it indirectly
and later return it, then the linker
has no chance to emit plt reloc for foo.

this is why i said plt should not be
considered part of the abi because it's
unreliable anyway.

> We should discuss making these features optional until we can work
> out a way to enable them without breaking LD_AUDIT and other tooling.
> Even if such an optimization is useful with `-z now`, the `now` binding
> is something we've been recommending for security purposes and having it
> remove PLT entries may have other consequences we haven't yet seen.
> As I had suggested before, some kind of `-z noplt` like the gcc feature
> to enable PLT eliding optimizations that may break existing developer
> tooling. This way we can start to approach users about the performance
> benefits and they can try it themselves. All the while we can work out
> how LD_AUDIT might be implemented in this case and eventually switch
> to it or admit defeat.
> Thoughts?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]