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

[Florian Weimer]

* Szabolcs Nagy:

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

The link editor could warn about mismatched accesses (especially if we
could mark an object for dynamic TLS, too).  Currently, you can have
mixed relocations within one object and nothing warns about it.
Theoretically, symbols could interposed, so the different TLS models
could be used for real, but that's really unusual, probably a bug, and
not really an argument against a linker warning (or an error).

Thanks,
Florian