libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libunwind-devel] tls_model("initial-exec") attribute prevents dynamic l


From: Milian Wolff
Subject: [Libunwind-devel] tls_model("initial-exec") attribute prevents dynamic loading of libunwind via dlopen()
Date: Sun, 29 Apr 2018 21:55:58 +0200

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
address@hidden
http://milianw.de

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]