Usage of the ELF STATIC_TLS flag & TLS type discovery at relocation

[Florian Weimer]

About twenty years ago, we had a DF_STATIC_TLS flag (in DT_FLAGS) that
indicated if an object uses static TLS (i.e., its TLS block is at a
fixed offset from the thread point, the offset being shared across all
threads).  It's still produced by some GNU/Linux targets, but not all of
them.

Instead, in the glibc implementation, the type of TLS is mostly
determined by the relocations used to reference TLS data.  As far as I
can see, there two exceptions: Initially loaded modules always use
static TLS.)  There is also a heuristic that can use static TLS even if
the relocation requests dynamic TLS because static TLS access can use a
fast path.

This is a bit unfortunate because we don't know where to allocate an
object until relocation processing is complete.  In the current glibc
implementation, this is not much of an issue because we can place TLS
for an object without changing its module ID or intra-block offsets for
TLS symbols.  It's easy to defer the placement decision until after
relocation processing is complete.  This flexibility comes at a run-time
cost because it requires another indirection.  We can of course record
the relocations as we encounter them during dlopen, and make a placement
decision based on the totality of the relocations encountered.  But I
wonder if the link editor could provide us the extra information we
need, at least for new targets.  For existing targets, we are
constrained by backwards compatibility.

Thanks,
Florian