Hi -

On Wed, Nov 01, 2006 at 12:03:36PM -0800, Roland McGrath wrote:
> Go team!  When I added the elfutils support for relocatability in August of
> last year, I was really hoping someone would start testing it one day. ;-)

Sorry for the wait.

> Is "somewhat longer" not an understatement?  [...]
> Note that
> dwfl_linux_kernel_report_offline lets you supply a predicate [...]

Right.

> which is the only way I've thought of to reduce the DWARF-loading
> overhead (without changing the way we install it).

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.

But failing that, we can probably make use of the existing predicate
function to cut down the work.

> You didn't change dwflpp::emit_address [...]

Yup, now done, at least an easy way (emitting an inline query every
time the relocatable $target variable is accessed).

It however exposes two problems with the newest symbol table code.
First, the new _stp_module_lookup function holds a spinlock on its
data structure, which could conceivably block.  This either needs
analysis to prove that this cannot happen, or else (what may be a good
idea anyway for performance reasons) we may need to relocate $target
addresses once during initialization, and keep a table.

The second problem is memory allocation.  Like ordinary associative
arrays, the new symbol table also appears to be allocated using what
comes down to kmalloc.  Unfortunately, with large number of entries of
either kind, this allocation can fail, or trigger OOM handling.

The runtime needs to learn to either rely more (perhaps exclusively)
on data segment allocation (.data or .bss arrays), or needs to make
sure that it fails in a clean way if kernel free memory happens to be
short.  This is essential.  (To see why, try running a script with
-DMAXMAPENTRIES=999999.)

- FChE