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

[Milian Wolff]

On Wednesday, May 2, 2018 4:37:22 PM CEST Dave Watson wrote:
> 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.

But there's already the --enable-per-thread-cache option which disables 
__thread. Isn't that enough for your use case?

> Facebook has codepaths that try to avoid the trace cache __thread if
> we actually need async-signal-safety:
> 
> https://github.com/facebook/folly/blob/cd1bdc912603c0358ba733d379a74ae90ab3a
> 437/folly/experimental/symbolizer/StackTrace.cpp#L31

Cheers

-- 
Milian Wolff
address@hidden
http://milianw.de