This is the mail archive of the binutils@sourceware.org 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 Thu, May 11, 2017 at 2:41 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> 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 <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?
>>
>> 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.

I checked in my patch now.

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

In both glibc and GCC, we don't try to use PLT.  It is quite opposite.
We are doing everything we can not to use PLT.  In case of

void *
foo_p ()
{
  foo ();
  return foo;
}

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.

-- 
H.J.


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