On x86_64-pc-linux-gnu I get with gcc-5 or gcc-6: FAIL: elf/check-localplt markus@x4 glibc-build % cat elf/check-localplt.out Missing required PLT reference: ld.so: realloc Missing required PLT reference: libc.so: realloc Missing required PLT reference: ld.so: malloc Missing required PLT reference: libc.so: calloc Missing required PLT reference: ld.so: __libc_memalign Missing required PLT reference: libc.so: memalign Missing required PLT reference: ld.so: calloc markus@x4 glibc-build % ld -v GNU ld (Gentoo git) 2.25.51.20150907
(In reply to Markus Trippelsdorf from comment #0) > On x86_64-pc-linux-gnu I get with gcc-5 or gcc-6: > > FAIL: elf/check-localplt > > markus@x4 glibc-build % cat elf/check-localplt.out > Missing required PLT reference: ld.so: realloc > Missing required PLT reference: libc.so: realloc > Missing required PLT reference: ld.so: malloc > Missing required PLT reference: libc.so: calloc > Missing required PLT reference: ld.so: __libc_memalign > Missing required PLT reference: libc.so: memalign > Missing required PLT reference: ld.so: calloc > > markus@x4 glibc-build % ld -v > GNU ld (Gentoo git) 2.25.51.20150907 This is a serious issue since it would mean that malloc et. al. are no longer interposable, and that users can no longer provide their own malloc implementation e.g. jemalloc, tcmalloc. Nobody else with GCC5 has seen thsi problem, might it be unique to your configuration? Are you using something like -fno-plot with -z relro and -z bindnow? It wouldn't be a standard configuration, but it's the only configuration I can think of that would be able to remove these PLT entries.
No, everything is pretty vanilla: CFLAGS="-g -O2 -pipe" CXXFLAGS="-g -O2 -pipe" ~/glibc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --with-headers=/usr/include --enable-add-ons --enable-kernel=4.0 --with-tls --with-__thread --enable-bind-now --without-gd --without-cvs --disable-profile --disable-multi-arch --disable-werror I just installed the resulting glibc and interposing malloc works just fine, e.g.: LD_PRELOAD=/usr/lib/libllalloc.so.1.3 some_program So it must be a false positive.
On 09/25/2015 02:26 PM, markus at trippelsdorf dot de wrote: > So it must be a false positive. So what does eu-readelf say about the DSO?
Looks good, e.g. /lib/ld-2.22.90.so: Relocation section [ 7] '.rela.dyn' at offset 0x878 contains 16 entries: Offset Type Value Addend Name 0x0000000000225d90 X86_64_RELATIVE 000000000000000000 +72544 0x0000000000225d98 X86_64_RELATIVE 000000000000000000 +67680 0x0000000000225da0 X86_64_RELATIVE 000000000000000000 +67104 0x0000000000225da8 X86_64_RELATIVE 000000000000000000 +77984 0x0000000000225db0 X86_64_RELATIVE 000000000000000000 +42976 0x0000000000225db8 X86_64_RELATIVE 000000000000000000 +84032 0x0000000000225dc0 X86_64_RELATIVE 000000000000000000 +87264 0x0000000000225dc8 X86_64_RELATIVE 000000000000000000 +96672 0x0000000000225dd0 X86_64_RELATIVE 000000000000000000 +82912 0x0000000000225dd8 X86_64_RELATIVE 000000000000000000 +106912 0x0000000000225fc8 X86_64_GLOB_DAT 0x000000000001a480 +0 __libc_memalign 0x0000000000225fd0 X86_64_GLOB_DAT 0x000000000001a580 +0 malloc 0x0000000000225fd8 X86_64_GLOB_DAT 0x000000000001a5a0 +0 calloc 0x0000000000225fe0 X86_64_GLOB_DAT 0x000000000001a7c0 +0 realloc 0x0000000000225fe8 X86_64_GLOB_DAT 0x0000000000227100 +0 _r_debug 0x0000000000225ff0 X86_64_GLOB_DAT 0x000000000001a5e0 +0 free
So I guess something like this is needed: diff --git a/sysdeps/x86_64/localplt.data b/sysdeps/x86_64/localplt.data index d140476dfeff..f168b143ff26 100644 --- a/sysdeps/x86_64/localplt.data +++ b/sysdeps/x86_64/localplt.data @@ -3,17 +3,17 @@ # users can define their own functions and have library internals call them. # Linker in binutils 2.26 and newer consolidates R_X86_64_JUMP_SLOT # relocation with R_X86_64_GLOB_DAT relocation against the same symbol. -libc.so: calloc +libc.so: calloc + RELA R_X86_64_GLOB_DAT libc.so: free + RELA R_X86_64_GLOB_DAT libc.so: malloc + RELA R_X86_64_GLOB_DAT -libc.so: memalign -libc.so: realloc +libc.so: memalign + RELA R_X86_64_GLOB_DAT +libc.so: realloc + RELA R_X86_64_GLOB_DAT libm.so: matherr # The dynamic loader uses __libc_memalign internally to allocate aligned # TLS storage. The other malloc family of functions are expected to allow # user symbol interposition. -ld.so: __libc_memalign -ld.so: malloc -ld.so: calloc -ld.so: realloc +ld.so: __libc_memalign + RELA R_X86_64_GLOB_DAT +ld.so: malloc + RELA R_X86_64_GLOB_DAT +ld.so: calloc + RELA R_X86_64_GLOB_DAT +ld.so: realloc + RELA R_X86_64_GLOB_DAT ld.so: free + RELA R_X86_64_GLOB_DAT
CCing H.J.
(In reply to Markus Trippelsdorf from comment #4) > Looks good, e.g. /lib/ld-2.22.90.so: > > Relocation section [ 7] '.rela.dyn' at offset 0x878 contains 16 entries: > 0x0000000000225fd0 X86_64_GLOB_DAT 0x000000000001a580 +0 malloc > 0x0000000000225fd8 X86_64_GLOB_DAT 0x000000000001a5a0 +0 calloc > 0x0000000000225fe0 X86_64_GLOB_DAT 0x000000000001a7c0 +0 realloc > 0x0000000000225fe8 X86_64_GLOB_DAT 0x0000000000227100 +0 _r_debug > 0x0000000000225ff0 X86_64_GLOB_DAT 0x000000000001a5e0 +0 free Please show me: # readelf -rW libc_pic.a | grep calloc | wc -l # readelf -rW libc_pic.a | grep calloc | grep -v R_X86_64_PLT32
On 09/25/2015 03:00 PM, markus at trippelsdorf dot de wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=19007 > > --- Comment #5 from Markus Trippelsdorf <markus at trippelsdorf dot de> --- > So I guess something like this is needed: > > -libc.so: calloc > +libc.so: calloc + RELA R_X86_64_GLOB_DAT This is a new binutils. I agree that HJ needs to think about how we want to represent this such that it work with old and new binutils.
markus@x4 glibc-build % readelf -rW libc_pic.a | grep calloc | wc -l 47 markus@x4 glibc-build % readelf -rW libc_pic.a | grep calloc | grep -v R_X86_64_PLT32 markus@x4 glibc-build %
A patch is posted at https://sourceware.org/ml/libc-alpha/2015-09/msg00655.html
Just to clarify: malloc etc. are still interposable, it's just a pure test case failure?
(In reply to Florian Weimer from comment #11) > Just to clarify: malloc etc. are still interposable, it's just a pure test > case failure? Yes.
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via d3d9c95aefded7716d037e241f9d23a1cccab45a (commit) from 8f763b04a0249d5a94a667da31294dd2395ec3bf (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d3d9c95aefded7716d037e241f9d23a1cccab45a commit d3d9c95aefded7716d037e241f9d23a1cccab45a Author: H.J. Lu <hjl.tools@gmail.com> Date: Wed Oct 14 05:59:50 2015 -0700 Support PLT and GOT references in local PIC check Linker in binutils 2.26 and newer generate GOT references instead PLT references when -z now is passed to linker. We need to extend scripts/localplt.awk to allow PLT or GOT references. [BZ #19007] * scripts/localplt.awk: Also allow GOT references. * sysdeps/unix/sysv/linux/i386/localplt.data: Mark _Unwind_Find_FDE, calloc, memalign, realloc and __libc_memalign with "+ REL R_386_GLOB_DAT". * sysdeps/x86_64/localplt.data: Mark calloc, memalign, realloc and __libc_memalign with "+ RELA R_X86_64_GLOB_DAT". ----------------------------------------------------------------------- Summary of changes: ChangeLog | 10 ++++++++++ NEWS | 6 +++--- scripts/localplt.awk | 2 +- sysdeps/unix/sysv/linux/i386/localplt.data | 16 ++++++++-------- sysdeps/x86_64/localplt.data | 14 +++++++------- 5 files changed, 29 insertions(+), 19 deletions(-)
Fixed.