[PATCH] Fix dladdr return value when cannot find symbol

Bernd Schmidt bernds_cb1 at t-online.de
Thu Feb 7 21:38:14 UTC 2008

Carmelo AMOROSO wrote:
> based on  the patch from Nickolai, here you can find a comprehensive
> patch to fix
> dladdr function.
> With the current implementation, the invocation of dladdr((void *) 1,
> &dlinfo)
> will fill dlinfo.dli_fname with the name of the application itself and
> dlinfo.dli_fbase with 0 (the current value of tpnt->loadaddr for the
> main app).
> The patch solves this adding a new field into the struct elf_resolve
> named  DL_LOADADDR_TYPE mapaddr.
> For shared objects, mapaddr has exactly the same value as loadaddr,
> while for the
> main app it contains the address of the first PT_LOAD segmented loaded.
> loadaddr will keep it's value and will used exactly as is (as a in
> memory offset
> with respect to relative addresses from ELF sections).
> While in the DL_ADDR_IN_LOADADDR macro, the new field mapaddr needs to
> be used.

This is broken on FD-PIC, since you treat DL_LOADADDR_TYPE variables as
pointers, defeating the point of abstracting away the type.

The following patch makes it compile on Blackfin, but I'm unable to test
this on a non-FDPIC system.  Does it still work for you?

This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapaddr.diff
Type: text/x-patch
Size: 4087 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20080207/4d6cb0f8/attachment-0002.bin 

More information about the uClibc mailing list