This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]