[PATCH] x86: Generate PLT relocations for -z now
H.J. Lu
hjl.tools@gmail.com
Thu May 11 14:51:00 GMT 2017
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.
More information about the Binutils
mailing list