This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Purpose of the elf/check-localplt test
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 2 Jan 2017 17:58:25 +0000
- Subject: Re: Purpose of the elf/check-localplt test
- Authentication-results: sourceware.org; auth=none
- References: <ccc0a507-e4d6-f108-707c-faa88cc3a121@redhat.com>
On Mon, 2 Jan 2017, Florian Weimer wrote:
> What's the exact purpose of elf/check-localplt?
>
> We do not want to use run-time relocations for calls within the same shared
> object on architectures which support efficient PC-relative calls. We also
> want to avoid interposable symbol references.
>
> But elf/check-localplt doesn't quite check these things. For example, on
> x86_64, all X86_64_GLOB_DAT relocations are ignored. Technically, this is
> perhaps correct because there is no PLT entry. But checking things this way
> seems to provide rather limited value.
It should be verifying: (a) that symbols that are meant to be interposed
can be interposed for glibc-internal calls; (b) that internal calls are
compiled optimally, not via the PLT. (I don't think it's trying to verify
(c) that symbols that aren't meant to be interposed can't be for
glibc-internal calls.)
It doesn't necessarily verify as much as ideal, the baselines include
known violations of (b) rather than reflecting the ideal set of
interposable symbols, and some parts of fully verifying (a) and (b) may be
hard. In the 32-bit x86 case, a call of a non-exported function is still
suboptimal if the function wasn't declared hidden (bug 18822), but the
test only covers exported functions so doesn't detect such cases.
--
Joseph S. Myers
joseph@codesourcery.com