What's the performance impact?
We have not measured. I was assuming nil or close because of the inlines.
How will it be when the more sophisticated reader hooks are used?
My expectation is that these will be inlines doing:
if (dbg->reloc) return fancy_business(); return read_blah_unaligned (...);
So it should be negligible for any non-ET_REL file. For ET_REL the cost of the fine-grained fancy business has to be compared to the full cost of doing __libdwfl_relocate beforehand with however many COW faults that entails. The usage pattern where this matters today is systemtap loading numerous .ko's, but then scanning through them quickly and actually consulting only a small subset of the data so a fraction of the reloc sites will actually incur the overhead (vs a huge startup delay with libdwfl's current eager relocation of whole sections in every module).
There are an awful lot of nested function calls. Although they are marked inline, are we sure gcc sees through that?
I don't think we have looked (probably not even tried an -O2 build).
Petr, can you eyeball the generated code, compare text sizes, etc.?
Thanks, Roland