build: use initial-exec TLS when building seastar as shared library

quote from
https://patchwork.ozlabs.org/project/glibc/patch/[email protected]/

> On the glibc side, we should recommend that intercepting mallocs and its
> dependencies use initial-exec TLS because that kind of TLS does not use
> malloc.  If intercepting mallocs using dynamic TLS work at all, that's
> totally by accident, and was in the past helped by glibc bug 19924.

so instead of allocating TLS variables using malloc, let's allocate them
using initial-exec TLS model. another approach is to single out the
static TLS variables in the code path of malloc/free and apply
`__attribute__ ((tls_model("initial-exec")))` to them, and optionally
only do this when we are building shared library.

but this could be overkill as

1. we build static library in the release build
2. the total size of the static TLS variables is presumably small, so
   the application linking against the seastar shared library
   should be able to afford this.

see also
https://patchwork.ozlabs.org/project/glibc/patch/[email protected]/
and
https://sourceware.org/bugzilla/show_bug.cgi?id=19924

Fixes scylladb#2247
Signed-off-by: Kefu Chai <[email protected]>

CMakeLists.txt

@@ -811,7 +811,16 @@ if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
  -Wno-error=deprecated-declarations)
 endif ()
 
-if (NOT BUILD_SHARED_LIBS)
+if (BUILD_SHARED_LIBS)
+ # use initial-exec TLS, as it puts the TLS variables in the static TLS space
+ # instead of allocates them using malloc. otherwise intercepting mallocs and
+ # friends could lead to recursive call of malloc functions when a dlopen'ed
+ # shared object references a TLS variable and it in turn uses malloc. the
+ # downside of this workaround is that the static TLS space is used, and it is
+ # a global resource.
+ list (APPEND Seastar_PRIVATE_CXX_FLAGS
+ $<$<IN_LIST:$<CONFIG>,RelWithDebInfo;Dev>:-ftls-model=initial-exec>)
+else ()
  list (APPEND Seastar_PRIVATE_CXX_FLAGS -fvisibility=hidden)
 endif ()