Em Wed, Jun 24, 2009 at 03:28:57PM -0700, Roland McGrath escreveu:
> Relocation is being always performed, but I don't need
this, is there a
> way for me to ask libdwfl to not perform relocations?
There are many layers of answer to give here. So I'll just spew out some
facts, and you can either give more context about your usage or ask more
specific questions from there.
Relocation is only relevant to ET_REL files, of which in normal practice
you'll only encounter .ko files for Linux kernel modules.
For me it is not relevant at all, I just need the type definitions and
function parameter list, variable name/type, etc. Only in very specific
cases I want addresses, and even then no need for relocations in most
>From what you cited, I don't know why you are looking at any
stuff at all in that use case. If you are just examining some normal DSO
file offline, then I can't imagine why you ever called dwfl_linux_kernel*
at all. Certainly you shouldn't be doing that on the same Dwfl object to
which you report that DSO file as a module, they are not sharing an
Well, I'm not using those functions at all:
[acme@doppio pahole]$ grep dwfl_linux_kernel *
Your trace indicates you called dwfl_linux_kernel_report_modules.
This does not cause any modules' DWARF files to be loaded at all,
by itself. It just reads /proc/modules and registers each module
in the Dwfl. You don't load any ELF/DWARF files at all until you
ask for one.
Probably thru one of the many callbacks and defaults in elfutils I may
well end up using something I haven't asked explicitely.
What I'm using that has a dwfl_ prefix is:
[acme@doppio pahole]$ grep dwfl_ *.[ch]
dwarf_loader.c: int build_id_len = dwfl_module_build_id(mod, &build_id, &vaddr);
dwarf_loader.c: Elf *elf = dwfl_module_getelf(dwflmod, &dwflbias);
dwarf_loader.c: Dwarf *dw = dwfl_module_getdwarf(dwflmod, &dwbias);
dwarf_loader.c: * __func__, dwfl_errmsg(-1));
dwarf_loader.c: /* Duplicate an fd for dwfl_report_offline to swallow. */
dwarf_loader.c: int dwfl_fd = dup(fd);
dwarf_loader.c: if (dwfl_fd < 0)
dwarf_loader.c: .section_address = dwfl_offline_section_address,
dwarf_loader.c: .find_debuginfo = dwfl_standard_find_debuginfo,
dwarf_loader.c: .find_elf = dwfl_build_id_find_elf,
dwarf_loader.c: Dwfl *dwfl = dwfl_begin(&callbacks);
dwarf_loader.c: if (dwfl_report_offline(dwfl, filename, filename, dwfl_fd) == NULL)
dwarf_loader.c: dwfl_report_end(dwfl, NULL, NULL);
dwarf_loader.c: dwfl_getmodules(dwfl, cus__process_dwflmod, &parms, 0);
dwarves.h: self->cached_symtab_nr_entries = dwfl_module_getsymtab(self->dwfl);
dwarves.h: name = dwfl_module_getsym(cu->dwfl, id, &sym, NULL); \
dwarves.h: ++id, name = dwfl_module_getsym(cu->dwfl, id, &sym, NULL))
I'll look at the dwfl internals to figure out where is that it ends up using
dwfl_linux_kernel_ prefixed routines...
If you were instead using dwfl_linux_kernel_report_offline, then it
make (a little) more sense. That does the equivalent of:
find /lib/modules/`uname -r` -name '*.ko'
and adds each of those as an offline file with dwfl_report_offline.
That is indeed a little slow (opens Elf handles on all those files),
but still it does not look at any DWARF. (To address just the file opening
overhead there you can use the PREDICATE parameter to avoid looking at what
you don't care about.)
So, clearly you are actually getting a Dwarf handle for each module from
libdwfl. I have no idea why you do that. This is what instigates the
relocation work. There is no way to get a usable DWARF handle for any
ET_REL file and avoid that relocation.
Finally, I'll mention that a future version of libdwfl will handle
ET_REL files differently. Instead of today's eager relocation of whole
sections before getting a Dwarf handle, libdw will do individual
relocation adjustments as needed while reading the DWARF data. This
will reduce the startup time to just get the Dwarf handle to similar to
that for non-ET_REL files, at the cost of higher overheads at fine grain
when you actually use individual pieces of DWARF data from an ET_REL file.
But it sure sounds like you are just asking explicitly for useless work
that you never need.
Well, as you can see above, I'm not. But it may well be that something like
dwfl_standard_find_debuginfo ends up pointing to kernel specific routines, I'll
check that in the elfutils sources.