[PATCH] Fix dladdr return value when cannot find symbol
carmelo.amoroso at st.com
Wed Jan 9 15:48:31 UTC 2008
Mike Frysinger wrote:
> On Wednesday 12 December 2007, Carmelo AMOROSO wrote:
>> while running more tests on this (indeed never used dladdr in the past),
> which tests ? our dl tests certainly dont have the coverage anywhere close to
> what i wish they did ...
based on the patch from Nickolai, here you can find a comprehensive
patch to fix
With the current implementation, the invocation of dladdr((void *) 1,
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
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
with respect to relative addresses from ELF sections).
While in the DL_ADDR_IN_LOADADDR macro, the new field mapaddr needs to
I hope I was clear enough in my explanation ;-)
Any comments are welcome.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the uClibc