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

[Szabolcs Nagy]

The 07/23/2024 10:11, Florian Weimer wrote:
> * 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).

what if there is no mismatched access, because there is no access?

mod1.so:
  __thread int x; // no access
  int *f(void);
  int *bar(){return f();}

mod2.so:
  extern __thread int x;
  int *f(){return &x;}