Created attachment 6727 [details] testcase Using the audit mechanism to redirect library lookups by implementing la_objsearch and returning a library that depends on libm.so (or libm.so itself) results in a subsequent segfault in the loader. I have attempted to create a standalone testcase, but did not succeed (I suspect the bug has to do with how IRELATIVE relocations are processed, but a simple testcase with IRELATIVE reloc works fine). Attaching a small testcase that depends on libm.so (and assumes it has IRELATIVE relocations). $ gdb --args /tmp/glibc-build/elf/ld.so --audit ./libaudit.so ./main GNU gdb (GDB) 7.4.1 (gdb) r Starting program: /tmp/glibc-build/elf/ld.so --audit ./libaudit.so ./main warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? Program received signal SIGSEGV, Segmentation fault. _dl_profile_fixup (l=0x7ffff7a33508, reloc_arg=4, retaddr=140737345060825, regs=0x7fffffffd1b0, framesizep=0x7fffffffd508) at ../elf/dl-runtime.c:176 176 DL_FIXUP_VALUE_TYPE value = *resultp; (gdb) bt #0 _dl_profile_fixup (l=0x7ffff7a33508, reloc_arg=4, retaddr=140737345060825, regs=0x7fffffffd1b0, framesizep=0x7fffffffd508) at ../elf/dl-runtime.c:176 #1 0x0000555555568306 in _dl_runtime_profile () at ../sysdeps/x86_64/dl-trampoline.h:48 #2 0x00007ffff7757fd9 in ?? () #3 0x00007fffffffd650 in ?? () #4 0x000055555555f5d1 in elf_machine_lazy_rel (skip_ifunc=<optimized out>, reloc=0x7ffff773e210, l_addr=140737344933888, map=0x7ffff7a33508) at ../sysdeps/x86_64/dl-machine.h:535 #5 elf_dynamic_do_Rela (skip_ifunc=<optimized out>, lazy=<optimized out>, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=0x7ffff7a33508) at do-rel.h:85 #6 _dl_relocate_object (scope=0x7ffff7a33860, reloc_mode=<optimized out>, consider_profiling=1, consider_profiling@entry=0) at dl-reloc.c:265 #7 0x0000555555557ad2 in dl_main (phdr=<optimized out>, phdr@entry=0x555555554040, phnum=4160734848, phnum@entry=7, user_entry=user_entry@entry=0x7fffffffd7d8, auxv=0x555555777801) at rtld.c:2299 #8 0x0000555555568afc in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7fffffffd890, dl_main=dl_main@entry=0x555555555ae0 <dl_main>) at ../elf/dl-sysdep.c:242 #9 0x0000555555558d0e in _dl_start_final (arg=0x7fffffffd890) at rtld.c:337 #10 _dl_start (arg=0x7fffffffd890) at rtld.c:563 #11 0x00005555555555a8 in _start () from /tmp/glibc-build/elf/ld.so (gdb) p l.l_reloc_result $1 = (struct reloc_result *) 0x0 (gdb) f 4 #4 0x000055555555f5d1 in elf_machine_lazy_rel (skip_ifunc=<optimized out>, reloc=0x7ffff773e210, l_addr=140737344933888, map=0x7ffff7a33508) at ../sysdeps/x86_64/dl-machine.h:535 535 value = ((ElfW(Addr) (*) (void)) value) (); (gdb) list 530 } 531 else if (__builtin_expect (r_type == R_X86_64_IRELATIVE, 0)) 532 { 533 ElfW(Addr) value = map->l_addr + reloc->r_addend; 534 if (__builtin_expect (!skip_ifunc, 1)) 535 value = ((ElfW(Addr) (*) (void)) value) (); 536 *reloc_addr = value; 537 } 538 else 539 _dl_reloc_bad_type (map, r_type, 1); (gdb)
Created attachment 6728 [details] simplified testcase Actually, redirecting libraries via LD_AUDIT mechanism is not required to trigger the bug. It suffices to use the minimal audit library that implements only la_version and an executable that links to libm.so. I'm surprised this simplified test fails. Is it covered in glibc's LD_AUDIT tests? Does it point to an inefficiency somewhere (LD_AUDIT library is essentially a no-op in this case, it's odd that the loader's behavior differs)?
Created attachment 6732 [details] standalone testcase Attached a standalone testcase that demonstrates the issue. This bug is a regression that prevents using LD_AUDIT with any executables that link against libm.so on some of the recent Linux distributions (and most of g++-compiled applications link with libm). I'm not familiar with the rtld guts at all, but here's my understanding of what happens: 1. elf_machine_lazy_rel calls the ifunc resolver 2. the resolver calls another function in the dso 3. the plt entry(?) has been instrumented for dso profiling, and calls _dl_profile_fixup. 4. _dl_profile_fixup accesses l->l_reloc_result, which is NULL and will be allocated later in _dl_relocate_object It seems to me that instrumenting for profiling is not necessary if the audit library does not export la_plt* routines. Thus, I think there are two separate issues here.
There are several audit tests: elf/tst-audit1.c elf/tst-auditmod1.c elf/tst-auditmod6a.c elf/tst-audit2.c elf/tst-auditmod3a.c elf/tst-auditmod6b.c elf/tst-audit3.c elf/tst-auditmod3b.c elf/tst-auditmod6c.c elf/tst-audit4.c elf/tst-auditmod4a.c elf/tst-auditmod7a.c elf/tst-audit5.c elf/tst-auditmod4b.c elf/tst-auditmod7b.c elf/tst-audit6.c elf/tst-auditmod5a.c elf/tst-audit7.c elf/tst-auditmod5b.c Do they fail for you?
They pass.
(In reply to comment #4) > They pass. Those tests are much more complex. Can add your testcase to elf directory and make it to fail?
Those tests do not exercise IFUNC at all. I could make a test suitable for the glibc test harness, but I already spent enough effort on producing a standalone test case that clearly demonstrates the issue in isolation. Have you tried my standalone testcase?
Created attachment 6733 [details] A testcase
A patch is posted at http://sourceware.org/ml/libc-alpha/2012-11/msg00334.html
Fixed on trunk by http://sourceware.org/git/?p=glibc.git;a=commit;h=2e64d2659d3edaebc792ac596a9863f1626e5c25 Need m68k/sh ELF_MACHINE_RUNTIME_FIXUP_PARAMS.
(In reply to comment #9) > Need m68k/sh ELF_MACHINE_RUNTIME_FIXUP_PARAMS. Completed in commit e510ab5efff3450b723dbe71734e8b22be14d1c6 (m68k), and commit d072f3f7724d85ceaf230806660235f0cf2f9c3b (SH).
Fixed on 2.16 branch.
*** Bug 13818 has been marked as a duplicate of this bug. ***