dlsym() may return an undefined symbol

Joakim Tjernlund joakim.tjernlund at transmode.se
Fri Jan 12 15:26:21 UTC 2007


Hi Cedric

Had a quick look at this and it migth be that the problem is easily
fixed by this:
Index: ldso/libdl/libdl.c
===================================================================
--- ldso/libdl/libdl.c	(revision 17166)
+++ ldso/libdl/libdl.c	(working copy)
@@ -442,7 +442,7 @@
 		}
 	}
 
-	ret = _dl_find_hash((char*)name, handle, NULL, 0);
+	ret = _dl_find_hash((char*)name, handle, NULL, ELF_RTYPE_CLASS_PLT);
 
 	/*
 	 * Nothing found.

However I am far from sure about this. Especially on other arch's than MIPS since
on MIPS type_class is always equal to ELF_RTYPE_CLASS_PLT for all other lookups

Would be great if you could test this on MIPS and x86.

 Jocke

> -----Original Message-----
> From: Cédric Hombourger [mailto:chombourger at nexwave-solutions.com] 
> Sent: 12 January 2007 14:10
> To: Joakim Tjernlund; uclibc at uclibc.org
> Subject: RE: dlsym() may return an undefined symbol
> 
> 
> Hello Jocke, thanks for your quick response and apologies for 
> the HTML post that I did. Yes I am more than aware that 
> 0.9.27 is rather old but we unfortunately have to integrate 
> our S/W component loader and runtime into a Linux-based 
> solution provided by a thirdparty (who delivers to us 
> binaries of the linux kernel, uclibc 0.9.27, and of their 
> software stack). We will push for an upgrade to 0.9.28... 
> 
> I have reproduced this behaviour with a SVN checkout of 
> uclibc from yesterday. Unfortunately, if I turn on traces 
> then I get a segv (that I will investigate). You will find 
> attached the test program that I used on mipsel-linux-uclibc 
> and below are the traces that I got with LD_DEBUG=all 
> defined. Note that the test program works just fine on 
> mipsel/glibc 2.3.2 (dlsym() returns the same pointer for both 
> calls) while on uclibc, the pointer returned by the second 
> dlsym() is a pointer to .MIPS.stubs resolving a completely 
> different symbol. 
> 
> Again thank you for your response, and please let me know if 
> there is something else you need.
> 
> Regards,
> Cedric Hombourger
> NexWave Solutions (www.nexwave-solutions.com)
> 
> 
> ---
> Trace dump after running export DEBUG=all; ./a.out
> 
> _dl_get_ready_to_run:630:       file='libdl.so.0';  needed by 
> './a.out'
> _dl_load_shared_library:222:    find library='libdl.so.0'; searching
> _dl_load_shared_library:298:    searching ldso dir='/lib'
> _dl_load_elf_shared_library:629: 
>         file='/lib/libdl.so.0';  generating link map
> _dl_load_elf_shared_library:630:                dynamic: 
> 0x2aaf012c  base: 0x2aaf0000
> _dl_load_elf_shared_library:632:                  entry: 
> 0x2aaf08c0  phdr: 0x2aaf0034  phnum: 0x7
> 
> _dl_get_ready_to_run:630:       file='libgcc_s.so.1';  needed 
> by './a.out'
> _dl_load_shared_library:222:    find library='libgcc_s.so.1'; 
> searching
> _dl_load_shared_library:298:    searching ldso dir='/lib'
> _dl_load_elf_shared_library:629: 
>         file='/lib/libgcc_s.so.1';  generating link map
> _dl_load_elf_shared_library:630:                dynamic: 
> 0x2ab340cc  base: 0x2ab34000
> _dl_load_elf_shared_library:632:                  entry: 
> 0x2ab357a0  phdr: 0x2ab34034  phnum: 0x4
> 
> _dl_get_ready_to_run:630:       file='libc.so.0';  needed by './a.out'
> _dl_load_shared_library:222:    find library='libc.so.0'; searching
> _dl_load_shared_library:298:    searching ldso dir='/lib'
> _dl_load_elf_shared_library:629: 
>         file='/lib/libc.so.0';  generating link map
> _dl_load_elf_shared_library:630:                dynamic: 
> 0x2ab8010c  base: 0x2ab80000
> _dl_load_elf_shared_library:632:                  entry: 
> 0x2ab8b810  phdr: 0x2ab80034  phnum: 0x6
> 
> _dl_get_ready_to_run:630:       file='libc.so.0';  needed by './a.out'
> _dl_load_shared_library:222:    find library='libc.so.0'; searching
> _dl_load_shared_library:298:    searching ldso dir='/lib'
> _dl_get_ready_to_run:630:       file='libc.so.0';  needed by './a.out'
> _dl_load_shared_library:222:    find library='libc.so.0'; searching
> _dl_load_shared_library:298:    searching ldso dir='/lib'
> 
> INIT/FINI order and dependencies:
> lib: /lib/libdl.so.0 has deps:
>  /lib/libc.so.0 
> lib: /lib/libgcc_s.so.1 has deps:
>  /lib/libc.so.0 
> lib: /lib/libc.so.0 has deps:
> 
> _dl_perform_mips_global_got_relocations for './a.out'
> _dl_perform_mips_global_got_relocations for '/lib/libdl.so.0'
> _dl_perform_mips_global_got_relocations for '/lib/libgcc_s.so.1'
> _dl_perform_mips_global_got_relocations for '/lib/libc.so.0'
> _dl_fixup:654: relocation processing: /lib/libc.so.0
> 
>         Segmentation fault (core dumped)
> 
> ________________________________
> 
> From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se] 
> Sent: Friday, January 12, 2007 12:06 AM
> To: Cédric Hombourger; uclibc at uclibc.org
> Subject: RE: dlsym() may return an undefined symbol
> 
> 
> Please don't post non plain text emails.
>  
> .27 is rather old and much has happened since then in ld.so.
>  
> your "fix" is broken. Can you repeat this with .28/or SVN ? 
> If so, enable SUPPORT_LD_DEBUG and
> run your test app. with LD_DEBUG=all defined 
>  
> Have you verified that this works as you expect on a glibc 
> based system?
>  
>  Jocke
>  
> 
> 
> 
> ________________________________
> 
> 	From: uclibc-bounces at uclibc.org 
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Cedric Hombourger
> 	Sent: den 11 januari 2007 23:15
> 	To: uclibc at uclibc.org
> 	Subject: dlsym() may return an undefined symbol
> 	
> 	
> 
> 	Hello there,
> 	
> 	With a program similar to the one below, we have 
> observed that dlsym of uclibc 0.9.27 may return the wrong 
> function pointer:
> 	
> 	librt = dlopen ("librt.so", RTLD_LAZY);
> 	libc  = dlopen ("libc.so", RTLD_LAZY);
> 	
> 	malloc1 = dlsym (libc, "malloc");
> 	res1 = malloc1 (16); // this one is ok, malloc() is called
> 	
> 	malloc2 = dlsym (librt, "malloc");
> 	res2 = malloc2 (16); // Ouch the stub for malloc from 
> librt.so / section .MIPS.stubs is returned!
> 	
> 	After tracing _dl_find_hash, I noticed the following 
> test which I don't understand:
> 	
> 	if (type_class & (sym->st_shndx == SHN_UNDEF)) continue;
> 	
> 	I did not understand the meaning of the type_class 
> parameter and why it should be non-zero for undefined symbols 
> to be ignored (and BTW dlsym() calls _dl_find_hash with a 
> zero type_class value).
> 	
> 	Changing the suspect line to:
> 	
> 	if ((sym->st_shndx == SHN_UNDEF)) continue;
> 	
> 	seem to have fixed the issue but frankly, I am not sure 
> whether this does not cause other issues.
> 	
> 	I fairly new to uclibc, any help/comment would be 
> highly appreciated.
> 	
> 	Note: it seems that this piece of code wasn't changed 
> in the latest snapshots - right?
> 	
> 	Regards,
> 	Cedric Hombourger
> 	NexWave Solutions (www.nexwave-solutions.com)
> 	
> 	
> 
> 



More information about the uClibc mailing list