This is the mail archive of the
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> <firstname.lastname@example.org> <591431AE.email@example.com>
On Thu, May 11, 2017 at 2:41 AM, Szabolcs Nagy <firstname.lastname@example.org> 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 <email@example.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
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.