[Mesa-dev] [PATCH] meson: add toggle for TLS support in GLX

[Rich Felker]

On Tue, Jan 29, 2019 at 11:32:59AM -0800, Eric Anholt wrote:
> Rich Felker <dalias at libc.org> writes:
> 
> > On Tue, Jan 29, 2019 at 08:29:32AM +0100, Patrick Steinhardt wrote:
> >> On Mon, Jan 28, 2019 at 02:09:18PM -0800, Dylan Baker wrote:
> >> > Quoting Adam Jackson (2019-01-28 09:00:13)
> >> > > On Sat, 2019-01-26 at 13:56 +0100, Patrick Steinhardt wrote:
> >> > > 
> >> > > > Unfortunately, I'm not aware of any easy way to do this. The
> >> > > > problem is not due to the compiler, as the program compiles and
> >> > > > links just fine with musl libc. Instead, this is a runtime issue
> >> > > > that happens when dlopen'ing shared objects with the
> >> > > > "initial-exec" TLS model. And as far as I understand, the error
> >> > > > only occurs if the PT_TLS segment size of the loaded shared
> >> > > > object exceeds the space preallocated for it by the libc.
> >> > > 
> >> > > You can hit that failure mode with glibc too, it just requires many
> >> > > more things trying to use TLS. Possibly we should reconsider whether
> >> > > initial-exec is really that important for performance anymore or if we
> >> > > can get away with global-dynamic.
> >> > > 
> >> > > - ajax
> >> > 
> >> > I seem to remember that this is problematic for other's than just musl, and that
> >> > our use of initial-exec works because of implementation details in glibc.
> >> > 
> >> > Like Eric, I really don't want this option added, I worked very hard to *NOT*
> >> > add this because there is a right answer in ever case, either you have working
> >> > TLS or you don't. The real frustration for me here is that musl absolutely
> >> > refuses to give us any way to identify it and turn off TLS automatically (which
> >> > is what we really want in this case).
> >> 
> >> Cc'ing Rich Felker, who is the maintainer of musl.
> >
> > Thanks. I think this is a good example of why we don't do that --
> > turning off TLS is the wrong "fix", and potentially introduces a
> > different bug: as best I can tell, the !TLS case has asm that assumes
> > pthread_getspecific does not clobber floating point/vector registers
> > that are call-clobbered per the ABI. This is likely true in practice,
> > but really it's up to the compiler that built musl whether it uses
> > them; there's no contract not to.
> >
> > What we would like from the musl side is for TLS to work correctly,
> > including when mesa is dynamically loaded. This avoids problems like
> > the above and should perform much better. I've been trying to get
> > feedback on how to proceed with this for a while, with no response:
> > https://bugs.freedesktop.org/show_bug.cgi?id=35268
> >
> > Are the mesa folks open to patches like what was discussed there?
> 
> Maintaining less code sounds great if the new TLS models actually work
> out.  We'd just want to see data indicating that the changes haven't
> hurt performance on affected architectures on glibc.

I don't have tests, but I do have results that the code the compiler
emits is almost identical to the asm if you use
-ftls-model=initial-exec (which should not be used, but which users
who still want an unsafe-to-dlopen .so tuned for maximal performance
could select), and that the code the compiler emits with
global-dynamic (default) and tls-dialect=gnu2 (tlsdesc) is roughly the
same as what I tried writing by hand before I found out there were
many different places the same idea had been duplicated.

Rich