This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: Way to disable relocations being performed
- From: Arnaldo Carvalho de Melo <acme at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Sun, 28 Jun 2009 17:57:02 -0300
- Subject: Re: Way to disable relocations being performed
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
cases.
> >From what you cited, I don't know why you are looking at any Linux kernel
> 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
> address/symbol space.
Well, I'm not using those functions at all:
[acme(a)doppio pahole]$ grep dwfl_linux_kernel *
[acme(a)doppio pahole]$
> 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(a)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);
dwarf_loader.c: dwfl_end(dwfl);
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))
[acme(a)doppio pahole]$
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 might
> 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.
- Arnaldo