Message ID | 20161104174739.GA5880@intel.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 8648 invoked by alias); 4 Nov 2016 17:47:42 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 8623 invoked by uid 89); 4 Nov 2016 17:47:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, NO_DNS_FOR_FROM, RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mga11.intel.com X-ExtLoop1: 1 Date: Fri, 4 Nov 2016 10:47:39 -0700 From: "H.J. Lu" <hongjiu.lu@intel.com> To: GNU C Library <libc-alpha@sourceware.org> Subject: [PATCH] Don't use PLT nor GOT in libc.a [BZ #20750] Message-ID: <20161104174739.GA5880@intel.com> Reply-To: "H.J. Lu" <hjl.tools@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) |
Commit Message
Lu, Hongjiu
Nov. 4, 2016, 5:47 p.m. UTC
There is no need to use PLT nor GOT in libc.a to branch to a function, regardless whether libc.a is compiled with PIC or not. Tested on x86-64. OK for master? H.J. --- [BZ #20750] * sysdeps/x86_64/sysdep.h (JUMPTARGET): Check SHARED instead of PIC. --- sysdeps/x86_64/sysdep.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On 11/04/2016 06:47 PM, H.J. Lu wrote: > There is no need to use PLT nor GOT in libc.a to branch to a function, > regardless whether libc.a is compiled with PIC or not. > > Tested on x86-64. OK for master? Isn't this header file used outside of libc as well? (And the commit message should mention that this change is specific to x86_64.) Thanks, Florian
On Fri, Nov 4, 2016 at 12:03 PM, Florian Weimer <fweimer@redhat.com> wrote: > On 11/04/2016 06:47 PM, H.J. Lu wrote: >> >> There is no need to use PLT nor GOT in libc.a to branch to a function, >> regardless whether libc.a is compiled with PIC or not. >> >> Tested on x86-64. OK for master? > > > Isn't this header file used outside of libc as well? It is used for other .a files. If they aren't used to create static binaries, PLT/GOT may be used. The resulting executable will work correctly. > (And the commit message should mention that this change is specific to > x86_64.) > I will update it.
On 11/04/2016 08:25 PM, H.J. Lu wrote: > On Fri, Nov 4, 2016 at 12:03 PM, Florian Weimer <fweimer@redhat.com> wrote: >> On 11/04/2016 06:47 PM, H.J. Lu wrote: >>> >>> There is no need to use PLT nor GOT in libc.a to branch to a function, >>> regardless whether libc.a is compiled with PIC or not. >>> >>> Tested on x86-64. OK for master? >> >> >> Isn't this header file used outside of libc as well? > > It is used for other .a files. If they aren't used to create static binaries, > PLT/GOT may be used. The resulting executable will work correctly. You mean because “name” is automatically mapped to “name@plt”? I find this comment not very illuminating: +/* For libc.a, we want to branch to target directly. */ # define JUMPTARGET(name) name And cheating the static linker in this way seems like a future maintenance hazard. Thanks, Florian
On Mon, Nov 7, 2016 at 8:03 AM, Florian Weimer <fweimer@redhat.com> wrote: > On 11/04/2016 08:25 PM, H.J. Lu wrote: >> >> On Fri, Nov 4, 2016 at 12:03 PM, Florian Weimer <fweimer@redhat.com> >> wrote: >>> >>> On 11/04/2016 06:47 PM, H.J. Lu wrote: >>>> >>>> >>>> There is no need to use PLT nor GOT in libc.a to branch to a function, >>>> regardless whether libc.a is compiled with PIC or not. >>>> >>>> Tested on x86-64. OK for master? >>> >>> >>> >>> Isn't this header file used outside of libc as well? >> >> >> It is used for other .a files. If they aren't used to create static >> binaries, >> PLT/GOT may be used. The resulting executable will work correctly. > > > You mean because “name” is automatically mapped to “name@plt”? No. There is no "@plt". Linker will create a PLT entry if the function is defined in a shared object. > I find this comment not very illuminating: > > +/* For libc.a, we want to branch to target directly. */ > # define JUMPTARGET(name) name > > And cheating the static linker in this way seems like a future maintenance > hazard. > It is ok as long as those static archives aren't used to create shared objects.
Ping. My distribution wants to enable PIE and -z,now by default and this is required for glibc to build. Allan On 08/11/16 03:13, H.J. Lu wrote: > On Mon, Nov 7, 2016 at 8:03 AM, Florian Weimer <fweimer@redhat.com> wrote: >> On 11/04/2016 08:25 PM, H.J. Lu wrote: >>> >>> On Fri, Nov 4, 2016 at 12:03 PM, Florian Weimer <fweimer@redhat.com> >>> wrote: >>>> >>>> On 11/04/2016 06:47 PM, H.J. Lu wrote: >>>>> >>>>> >>>>> There is no need to use PLT nor GOT in libc.a to branch to a function, >>>>> regardless whether libc.a is compiled with PIC or not. >>>>> >>>>> Tested on x86-64. OK for master? >>>> >>>> >>>> >>>> Isn't this header file used outside of libc as well? >>> >>> >>> It is used for other .a files. If they aren't used to create static >>> binaries, >>> PLT/GOT may be used. The resulting executable will work correctly. >> >> >> You mean because “name” is automatically mapped to “name@plt”? > > No. There is no "@plt". Linker will create a PLT entry if the function > is defined in a shared object. > >> I find this comment not very illuminating: >> >> +/* For libc.a, we want to branch to target directly. */ >> # define JUMPTARGET(name) name >> >> And cheating the static linker in this way seems like a future maintenance >> hazard. >> > > It is ok as long as those static archives aren't used to create shared > objects. >
On 11/24/2016 12:58 PM, Allan McRae wrote: > Ping. My distribution wants to enable PIE and -z,now by default and > this is required for glibc to build. My question has been answered. H.J., could you please check this in? Thanks, Florian
On 24/11/16 11:58, Allan McRae wrote: > Ping. My distribution wants to enable PIE and -z,now by default and > this is required for glibc to build. > how does this help? i think glibc has no static pie entry point that can resolve relative relocs of pie code.. (i think only musl libc supports this now, used in the alpine linux distro, which have some toolchain patches to make it work).
diff --git a/sysdeps/x86_64/sysdep.h b/sysdeps/x86_64/sysdep.h index 75ac747..fd25c90 100644 --- a/sysdeps/x86_64/sysdep.h +++ b/sysdeps/x86_64/sysdep.h @@ -89,13 +89,14 @@ lose: \ END (name) #undef JUMPTARGET -#ifdef PIC +#ifdef SHARED # ifdef BIND_NOW # define JUMPTARGET(name) *name##@GOTPCREL(%rip) # else # define JUMPTARGET(name) name##@PLT # endif #else +/* For libc.a, we want to branch to target directly. */ # define JUMPTARGET(name) name #endif