Future directions for the dynamic linker auditing (LD_AUDIT) interface

[Florian Weimer]

* Jonathon Anderson:

> Regarding the "challenge," for example PC sampling requires an
> up-to-date representation of the address space which includes the
> auditor. If auditors cannot "see" libraries they dlopen() then the
> address space will slip out-of-date while code (constructors) is
> running from the newly loaded library. If an asynchronous sample is
> taken during that delicate time a stack unwind will ultimately fail.

I assume you do this to maintain lookaside tables for PC lookup.  Do you
do that for access from within the process, or are the tables exposed
for use by external tools?

For the in-process PC lookup, we have _dl_find_object these days.  Maybe
that's what you need?  It's supposed to be async-signal-safe (even if
interrupting dlopen), so that it can be called from a SIGPROF handler.
If it's not fast enough but would otherwise fit, we can look at ways how
to make it go faster still, especially for the many-objects case.

> I believe this issue is something the shim can work around (e.g. with
> an extra dlmopen() namespace), so I'm not too concerned yet, but it's
> something to be aware of.

Yes, you could use extended _r_debug to walk all namespaces and populate
lookup tables this way.  We should probably document that the list is
stable when an auditor callback is invoked.

Thanks,
Florian