On Wednesday, 3 October 2018 1:44:05 PM NZDT Khem Raj wrote: > Musl started blocking dlopen of libs with initial-exec references into > dynamic TLS area, via > > https://github.com/kraj/musl/commit/5c2f46a214fceeee3c3e41700c51415e0a4f1acd > > prior to that commit, musl was loading it and silently letting > subsequent TLS accesses via the miscompiled code clobber memory that > didn't belong to them > > This was wrong behavior and it relied on additional space reserved by > libc in TLS space to adjust fo such broken libs, but it also fails > with glibc if the reserved space was already used up > > Right fix is that mesa should be patched to remove all the > initial-exec hacks and use real TLS, and -mtls-dialect=gnu2 (TLSDESC) > should be used on archs it's supported on (i386, x86_64, and aarch64) > to make up for the lost performance, but mesa hardcodes the initial-exec, > so there must be a reason that probably is better known to mesa devs. > > but we 'fixed' it for musl by adding --disable-glx-tls for mesa in OE, > which uses pthread_getspecific instead and makes is lot slower. > > this caused additional problems with security flags on, it get textrels > in .text segment. Therefore this is 'second fix' to get us through this > warning. > > Cause is some unknown part of mesa's x86 assembly code is broken by > readonly text segments
That's excellent, thanks! Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
