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