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

[Bert Wesarg]

Dear Milian,

I tried to remember why we choose the initial-exec model, but could
not found any reasons. By reading
https://www.akkadia.org/drepper/tls.pdf again, I would say
"local-exec" is the right way to go here. Which should be the default
for 'static' variables anyway. Can you please confirm, that this works
for you. Its just important, that there are no calls to
__tls_get_addr() in the asm output.

Thanks.

Bert

On Sun, Apr 29, 2018 at 9:55 PM, Milian Wolff <address@hidden> 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?
>
> 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
> _______________________________________________
> Libunwind-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/libunwind-devel
>