This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Avoid PLT when calling __sched_getaffinity_new
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 14 Oct 2015 15:19:01 +0000
- Subject: Re: [PATCH] Avoid PLT when calling __sched_getaffinity_new
- Authentication-results: sourceware.org; auth=none
- References: <20150821170918 dot GA29943 at intel dot com> <561E4D6C dot 9040303 at redhat dot com> <CAMe9rOqT6cGee5iXWbqPfvZqYf=z53O-2LggQ-xGkMwQ+o1XAA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1510141502410 dot 20331 at digraph dot polyomino dot org dot uk> <CAMe9rOotkAY+ZO8_28FBzYdKO2ddj+6ZFdsOg81M2u6wj8fftQ at mail dot gmail dot com>
On Wed, 14 Oct 2015, H.J. Lu wrote:
> I don't have a testcase yet. After removing all unnecessary PLT relocations
> on i386 and x86-64, we can do something similar to scripts/localplt.awk
> to check libc_pic.a. Each arch can provide its own list, similar to
> localplt.data.
Note that this applies to all .so files installed by glibc (if a symbol
should always be resolved within the same shared library, then this should
be visible to the compiler by it being marked hidden at compilation time),
not just libc.so.
I wonder about a non-architecture-specific approach along the lines of: if
an object (in *_pic.a) has a relocation against a symbol (not local to
that object file) not exported from its shared library, or (for functions
but not for data) exported only at a non-default version, the symbol must
have hidden visibility in that object. (The special case for data symbols
at non-default versions is because using aliases for data symbols is
generally unsafe - it breaks the link between the library's reference to
the symbol and the main executable's definition.)
--
Joseph S. Myers
joseph@codesourcery.com