dladdr() when called with a shared library symbol like printf returns the name of the main executable in dli_fname I suspect it happens because it resolves the PLT, but that's clearly unexpected and makes it hard to use if you want to know what .so printf is in. Is there a way around it? Maybe the function could check for PLTs and resolve them?
Created attachment 7675 [details] dladdr arm vs x86_64 different behavior example compiled with g++ main.cpp -o main -Wall -Wextra -ldl -fPIC
As suggested in the dladdr() man-page, compiling your code to be position independent, using -fPIC for example, may cause dladdr to return the path to the shared library the symbol comes from rather than return the path to the executable. However, one issue with this that I've noticed is that when building on or cross-compiling for armv7l, dladdr will always return the path to the executable for exported symbols that also happen to be called within the program. When compiled with /usr/bin/g++-4.7 main.cpp -o main-ARM -Wall -Wextra -ldl -fPIC the attached example program prints "printf comes from /lib/x86_64-linux-gnu/libc.so.6" on x86_64 machines and "printf comes from ./main" on armv7l