Rich Felker <dal...@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.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
