On Dienstag, 23. Februar 2016 17:41:55 CET Jonathan Byrd wrote: > On Mon, 22 Feb 2016 at 16:10:51 Arun Sharma wrote: > > The only known work around is to > > implement your own dl_iterate_phdr that doesn't call malloc by hooking > > into low level APIs that notify you every time a new shared object is > > loaded. > > The attached patch adds the function 'unw_set_iterate_phdr_function' to > the libunwind API, allowing a custom implementation of dl_iterate_phdr() > to be hooked in. That implementation would need to maintain a local > cache (or however else you wanted to manage it) to remove the need for > taking the glibc loader lock.
Nice, I played around with this patch yesterday and it seems to work quite nicely. In my implementation, I cached the results from a dl_iterate_phdr call which seems to stay valid until the next dlopen/dlclose call is issued, at which point I invalidate the cache and update it on demand the next time then. For my use-case (heaptrack) I think I'll be able to leverage this to gain a considerable performance boost: Instead of serializing the individual iterations, I should be able to use a shared mutex. I.e. only updating the cache as a write operation must be serialized while the read operations can be done in parallel. So +1 from my side to get this patch in. Cheers! -- Milian Wolff [email protected] http://milianw.de
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
