Re: [Libunwind-devel] tls_model("initial-exec") attribute prevents dynamic loading of libunwind via dlopen()

[Dave Watson]

On 04/29/18 09:55 PM, Milian Wolff wrote:
> 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?

As Paul mentioned, it's because __thread and friends aren't
async-signal-safe on glibc and may allocate.  I'm fine adding a
configure-time option to change the tls model if someone wants to
provide a patch for it.

Facebook has codepaths that try to avoid the trace cache __thread if
we actually need async-signal-safety:

https://github.com/facebook/folly/blob/cd1bdc912603c0358ba733d379a74ae90ab3a437/folly/experimental/symbolizer/StackTrace.cpp#L31