This is the mail archive of the libc-alpha@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]

Re: Should undefined symbols in sysv hash table be ignored in do_lookup_x?


On Thu, Feb 7, 2013 at 11:38 AM, Roland McGrath <roland@hack.frob.com> wrote:
> Is there any reason not to move the change into check_match?  Its only
> other caller is the DT_GNU_HASH case, which it doesn't affect since that
> table never has such symbols.  But check_match already checks for SHN_UNDEF
> contingent on type_class, so the existing check would be simplified by
> always catching SHN_UNDEF.

It turns out that values of undefined function symbols in gnu hash
table:

[hjl@gnu-6 glibc-32bit-test]$ readelf -D -s /bin/ld| grep UND
  208   1: 0000000000404280     0 FUNC    GLOBAL DEFAULT UND xmalloc
  211   3: 0000000000403e40     0 FUNC    GLOBAL DEFAULT UND free
  213   3: 0000000000404a10     0 FUNC    GLOBAL DEFAULT UND
_bfd_elf_match_sections_b
  217   5: 0000000000404070     0 FUNC    GLOBAL DEFAULT UND bfd_hash_newfunc
[hjl@gnu-6 glibc-32bit-test]$

are their PLT entries, which are used as function address.  i386 and x86-64
treat TLS relocations as PLT relocations:

/* ELF_RTYPE_CLASS_PLT iff TYPE describes relocation of a PLT entry or
   TLS variable, so undefined references should not be allowed to
   define the value.

This patch

diff --git a/elf/dl-lookup.c b/elf/dl-lookup.c
index 68f8dac..854bc52 100644
--- a/elf/dl-lookup.c
+++ b/elf/dl-lookup.c
@@ -134,7 +134,8 @@ do_lookup_x (const char *undef_name, uint_fast32_t new_hash,
   assert (ELF_RTYPE_CLASS_PLT == 1);
   if (__builtin_expect ((sym->st_value == 0 /* No value.  */
                && stt != STT_TLS)
-              || (type_class & (sym->st_shndx == SHN_UNDEF)),
+              || ((type_class || stt == STT_TLS)
+              & (sym->st_shndx == SHN_UNDEF)),
               0))
     return NULL;

works.  Only ppc64, am33 and mips don't treat TLS relocations as
PLT relocations.


-- 
H.J.


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