Re: offline elfutils processing committed

[Roland McGrath <roland at redhat dot com>]

> It would be nice if we didn't have to know ahead of time which modules
> we'd need, that is, if elfutils were to pass us placeholder structs
> with nothing but names, to get it to fetch module contents only when
> we query further.

That is already how it works.  The offline module reporting is surely
somewhat slower than the live kernel module enumeration, because it does
the equivalent of find /lib/modules/foo -name '*.ko' rather than the
equivalent of cat /proc/modules.  But the big slowdown I was referring to
is the actual loading of the DWARF info.  That doesn't happen until you
request it.  If you only ever use dwfl_module_* calls to get DWARF info out
of an individual module, no other module's info will be loaded.  I thought
systemtap was using some of the global iterators like dwfl_nextcu, which
asks for DWARF info from all modules.  To do all-modules matches on source
file names and the like you unavoidably have to load each and every
module's DWARF info.

> idea anyway for performance reasons) we may need to relocate $target
> addresses once during initialization, and keep a table.

I am a little shocked that you were ever doing anything different.  I
always figured that you would collect at translation time the set of
relocation bases you need and have emit_address and the like emit things
like "base27 + 0x123".  At module initialization time each static variable
like base27 gets initialized with its module+section runtime location.