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

[Szabolcs Nagy]

The 07/22/2024 18:32, Florian Weimer wrote:
> 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

note: currently we don't know where to allocate an object
until either

- a dynamic tls access happens in user code or

- a relocation for tls in the object is processed that
  allows/requires static tls which may be another module
  that's loaded much later.

this is because map->l_tls_offset is set to NO_TLS_OFFSET
and only updated at tls access time or for static tls relocs.

thus GD tls access needs locks around l_tls_offset access,
which is ugly (currently it's just that since there is no
as-safety guarantee) i opened
https://sourceware.org/bugzilla/show_bug.cgi?id=32004

> 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.

it makes sense to fix the missing DF_STATIC flag for
elf conformance, but we can work it around and

DF_STATIC does not help if the module does not have
IE access to its tls but a dependency does, the link
editor is likely not smart enough to see that.

> 
> Thanks,
> Florian
>