Hey all. I just noticed that one cannot dlopen() libunwind when it is build with -- enable-per-thread-cache. In such scenarios, dlopen will always fail with "cannot allocate memory in static TLS block".
The issue was also encountered by the jemalloc people, see [1] and [2]. [1]: https://github.com/jemalloc/jemalloc/issues/937 [2]: https://github.com/jemalloc/jemalloc/pull/1180 The reason for this in libunwind comes from src/dwarf/Gparser.c: static __thread struct dwarf_rs_cache tls_cache __attribute__((tls_model("initial-exec"))); The initially specified tls_model("initial-exec") triggers the issue above. jemalloc has work-arounded this by adding a configure option to remove this explicit tsl_model setting (cf. [2] above). Indeed, just removing the attribute "fixes" libunwind for my use-case in heaptrack. So the question is now: - why was the tls_model explicitly set to initial-exec? - can we just remove it? - if not, can we add another configure option similar to what jemalloc did? Note that the other thread local caches, such as the following in the platform specific Gtrace.c files, also just uses the default tls model: static __thread unw_trace_cache_t *tls_cache; So from my side, I propose we just remove the tls_model attribute. Thanks -- 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
