On Tue, Jan 29, 2019 at 11:32:59AM -0800, Eric Anholt wrote: > Rich Felker <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
