[PATCH] Fix dladdr return value when cannot find symbol
carmelo.amoroso at st.com
Fri Feb 8 09:24:40 UTC 2008
Bernd Schmidt wrote:
> 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,
>> 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?
the fix is fine for me too.. sorry I did not take care of the
specificity of bfin.
Please, go ahead and commit it. I'll update the nptl branch too.
More information about the uClibc