Steven Newbury wrote:
On Sun, 2004-07-11 at 20:10, Ian Romanick wrote:
These two patches cooperate to enable TLS support. For now you much manually add "#define GlxUseThreadLocalStorage YES" to your host.def to enable TLS support. Apply the Mesa patch to the Mesa tree and the DRI patch to the DRI tree.
Right now libGL will try for a TLS driver first, and fallback to the non-TLS driver if tls/*_dri.so does not exist. I am considering adding an env variable to make libGL ignore the TLS drivers altogether. The only catch with this would be that using the env var would not disable libGL's use of TLS.
There are a couple gaps in my understanding of TLS. I hope that someone on the list can fill me in. I've seen that a few apps require 'LD_ASSUME_KERNEL=2.4.19' to disable TLS. Doing that with, for example, glxgears doesn't seem to make any difference. It still uses the TLS libGL.so and the TLS driver. What is this option /really/ supposed to do?
The option makes the the ld.so dynamic loader use the non-TLS version of the C libraries. It is a RedHat hack to enable the use of both TLS and non-TLS libraries at the same time (so that older kernels still work on new installations).
It doesn't seem to be Redhat specific. I won't comment about the hack part. ;) At the very least the version of SuSE on my box does the same thing.
On modern i386 RedHat based systems within the /lib directory there are i686 and tls subdirectories. Which libraries are dynamically linked depends on rules within the dynamic linker. The glibc lib is compiled multiple times with support for tls and architecture optimisations (usually i686), no support for tls but with architecture optimisations, and for i386 (ie no optimisations).
I suspect the libGL is explicitly loading TLS libraries rather than
using the system ld.so dynamic linker.
Right. I guess there are two questions, then:
1. How do we get the .note.ABI-tag section in our libGL when it is built to use TLS?
2. How do we hack up the build to generate TLS and non-TLS libGL and drivers?
I'm particularly interested in hearing suggestions on #2 from folks (you know who you are) that have more TLS experience. :)
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
