This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/18422] elf/tst-audit tests fail without PLT entries


https://sourceware.org/bugzilla/show_bug.cgi?id=18422

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
The error message was

no PLTREL found in object
/export/build/gnu/glibc-test/build-x86_64-linux/elf/ld.so

since ld.so was built with -z now. After

commit 3e058c9d7eab6d6361e7cda5ba1394bc1757c9f6
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri May 22 17:46:42 2015 -0700

    Don't issue an error if DT_PLTRELSZ is missing

    A shared object doesn't need PLT if there are no PLT relocations.  It
    shouldn't be an error if DT_PLTRELSZ is missing.

      [BZ #18410]
      * elf/dl-reloc.c (_dl_relocate_object): Don't issue an error
      for missing DT_PLTRELSZ.

the error message is gone.  But there is still:

FAIL: elf/tst-audit2

elf/tst-audit2.c has

/* This calloc definition will be called by the dynamic linker itself.
   We test that it has initialized our TLS block by the time it does so.  */

void *
calloc (size_t n, size_t m)
{
  if (magic[0] != MAGIC1 || magic[1] != MAGIC2)
    {
      printf ("{%x, %x} != {%x, %x}\n", magic[0], magic[1], MAGIC1, MAGIC2);
      abort ();
    }
  magic[0] = MAGIC2;
  magic[1] = MAGIC1;

Since ld.so is built with -z now, there are no PLT relocations and this calloc
won't be used:

Relocation section '.rela.dyn' at offset 0x8a8 contains 16 entries:
  Offset          Info           Type           Sym. Value    Sym. Name +
Addend
000000221d48  000000000008 R_X86_64_RELATIVE                    10160
000000221d50  000000000008 R_X86_64_RELATIVE                    f070
000000221d58  000000000008 R_X86_64_RELATIVE                    ee30
000000221d60  000000000008 R_X86_64_RELATIVE                    11410
000000221d68  000000000008 R_X86_64_RELATIVE                    9c10
000000221d70  000000000008 R_X86_64_RELATIVE                    129c0
000000221d78  000000000008 R_X86_64_RELATIVE                    12e20
000000221d80  000000000008 R_X86_64_RELATIVE                    14da0
000000221d88  000000000008 R_X86_64_RELATIVE                    12570
000000221d90  000000000008 R_X86_64_RELATIVE                    16e40
000000221f98  000b00000006 R_X86_64_GLOB_DAT 00000000000170d0
__libc_memalign@@GLIBC_2.2.5 + 0
000000221fa0  001700000006 R_X86_64_GLOB_DAT 00000000000171d0
malloc@@GLIBC_2.2.5 + 0
000000221fa8  000e00000006 R_X86_64_GLOB_DAT 00000000000171e0
calloc@@GLIBC_2.2.5 + 0
000000221fb0  000700000006 R_X86_64_GLOB_DAT 0000000000017390
realloc@@GLIBC_2.2.5 + 0
000000221fb8  000900000006 R_X86_64_GLOB_DAT 0000000000223120
_r_debug@@GLIBC_2.2.5 + 0
000000221fc0  000600000006 R_X86_64_GLOB_DAT 0000000000017220 free@@GLIBC_2.2.5
+ 0

Assuming we do want to keep PLT relocations in ld.so so that malloc functions
in ld.so can be overridden, I don't think ld.so should be built with -z now.
There is no reason to build ld.so with -z now since ld.so is the one doing
BIND_NOW.  The only thing we get with -z now on ld.so is

 0x0000000000000018 (BIND_NOW)           
 0x000000006ffffffb (FLAGS_1)            Flags: NOW

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]