On Tue, 2017-01-31 at 14:39 +0100, Milian Wolff wrote: > should I be able to resolve kernel addresses to symbol names with elfutils > libdwfl?
Yes. See also eu-addr2line -k -S which I believe does what you are trying to do below. > I did something like this: > > m_dwfl = dwfl_begin(m_callbacks); > auto i_k = dwfl_linux_kernel_report_kernel(m_dwfl); > auto i_m = dwfl_linux_kernel_report_modules(m_dwfl); > > Both i_k and i_m returned 0. Then, I picked a random address from my /proc/ > kallsyms, e.g.: > > ffffffff81001000 T hypercall_page > > and try to find that symbol: > > auto module = dwfl_addrmodule(m_dwfl, 0xffffffff81001000ll); > > The module is non-null and points me at this module (comparing to output I > get > from dwfl_getmodules): > > 0x61400000fa40 kernel ffffffff81000000 You could also use dwfl_module_info () to get the name and other information about the module found for that address. > But when I try to get a symbol, I get a nullptr: > > auto sym = dwfl_module_addrname(module, 0xffffffff81001000ll); > > So, what am I missing? I don't immediately know without seeing the full program. You could try using dwfl_module_addrinfo () to see if you can get more information about the address in that module. You could also try calling dwfl_module_getsymtab () on the module and look at some of the symbols found with dwfl_module_getsym_info () to see if libdwfl found the symbol table for that module. > Also, it doesn't seem to be possible to specify the path to the kallsyms file > with the current dwfl_linux_kernel_report_kernel API - how is this intended > to > be handled? Should one instead use dwfl_linux_kernel_report_offline when one > wants to support cross-machine analysis? Yes, one should use dwfl_linux_kernel_report_offline when cross-machine (or even just cross kernel version) analysis. The /proc/kallsyms file is only used to estimate some running kernel address boundaries (but isn't strictly necessary).
