[uClibc] libdl (dlopen/dlsym) broken from statically linked executable

Eric Hassold hassold at evolane.fr
Tue Jul 19 02:19:19 UTC 2005


Hi,

Current (svn) libdl implementation in uClibc (dlopen() and friends) 
segfault if called from a statically linked executable, since 
_dl_symbol_tables is implicitly assumed to be non-NULL in dlopen() and 
dlsym() (which is true for dynamic exes), and dereferenced (while its 
initial value is NULL when called from a static executable).

As a quick hack, I protected three occurences in libdl.c (two in 
dlopen() and one in dlsym()) where this NULL pointer was dereferenced 
(see attached patch), and everything *apparently* works again.

Another solution may consist in allocating a (eventually blank) dyn_elf 
structure (and its associative elf_resolve as "dyn" member) to set 
_dl_symbol_tables with a non-empty value.

Calling something like:

#if !defined (__LIBDL_SHARED__)
_dl_symbol_tables = (struct dyn_elf *) _dl_malloc(sizeof(struct dyn_elf));
_dl_memset(_dl_symbol_tables, 0, sizeof(struct dyn_elf));
_dl_symbol_tables->dyn = _dl_loaded_modules;
_dl_symbol_tables->next = NULL;
_dl_symbol_tables->dyn = (struct elf_resolve *) _dl_malloc(sizeof(struct
elf_resolve));
_dl_memset(_dl_symbol_tables->dyn, 0, sizeof(struct elf_resolve));
#endif

prior to any invocation of dlopen(), dlsym(),... also makes dynamic 
loading from static exes works again.

Whatever "best" solution is, I look forward having dlopen() works again 
from statically linked apps in much awaited with enthusiasm 0.9.28 release.

 -Eric

-----

Eric Hassold
http://www.evolane.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libdl.patch
Type: text/x-patch
Size: 1278 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20050719/d346bf66/attachment.bin 


More information about the uClibc mailing list