This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86: Generate PLT relocations for -z now
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, Binutils <binutils at sourceware dot org>, GNU C Library <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Thu, 11 May 2017 07:51:03 -0700
- Subject: Re: [PATCH] x86: Generate PLT relocations for -z now
- Authentication-results: sourceware.org; auth=none
- References: <20170508202153.GA28618@intel.com> <146b87ef-0c8c-c829-18e1-41db38df5fd1@redhat.com> <591431AE.6000201@arm.com>
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.