Re: Way to disable relocations being performed

[Roland McGrath <roland at redhat dot com>]

> 	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.  

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.

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.

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.


Thanks,
Roland