I wrote a small function to create a callstack in c++, using bfd to resolve the addresses. It works fine and I get detailed information (source file and line) for all functions inside the current application, but I get no information what-so-ever about shared libraries that are included in my application.
For example:
callstack:
[0x00002b54229ba6d3 .none] <not sectioned address>
[0x00002b5422927907 .none] <not sectioned address>
[0x00002b54229286d0 .none] <not sectioned address>
[0x00000000004f8608 .text] tensorNetwork.hxx:63 (inside operator())
[0x00000000005528da .text] /usr/include/c++/4.8/functional:2058 (inside _M_invoke)
[0x000000000058231c .text] /usr/include/c++/4.8/functional:2469 (inside std::function<bool ()>::operator()() const)
[0x00000000005806c0 .text] test.cpp:26 (inside ___test(std::pair<std::string, std::function<bool ()> > const&))
[0x0000000000581693 .text] test.cpp:119 (inside main)
[0x00002b5423fdebe5 .none] <not sectioned address>
[0x000000000042c129 .text] /home/abuild/rpmbuild/BUILD/glibc-2.18/csu/../sysdeps/x86_64/start.S:125 (inside _start)
As you can see the symbols of the executable and the static object that got linked with the application are resolved correctly, but the address in the high ranges (eg. 0x00002b54229ba6d3) are not. These addresses are not part of either my application or my shared library file. Further tools like addr2line thus cannot reconstruct the position of that instruction either.
That I cannot resolve these addresses with the bfd tools is somewhat expected as long as I only open the file on disc to get the symbols (what I currently do is abfd = bfd_openr("/proc/self/exe", 0);), so is there a way to get the bfd of the currently running process (thus including the sections of the shared libraries)? If not: how can I get a list of loaded shared objects and their offset and how can I relate these offsets to the shared object files on disc (such that I may load the bfd of the .so file separately)?
The glibc adds a function to the
dllibrary calleddladdr. With it it is possible to find the filename of the shared object and its loaded memory offset. Loading these object files withbfd_openrallowed me to dump the source-files and lines similar to how addr2line would do it (but still dump some information in case these are not available). For example (notice that thelibc6.sodoes not contain debug symbols on my system and thus only the closest exported symbol is shown):In case someone needs the same functionality (I found it annoyingly difficult to create a nice callstack) here is the sourcecode (as part of our library licensed under the AGPLv3):