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