It has to process its own program headers to find the TLS image and copy it to main thread's TLS, but that doesn't involve file loading.
-
-
A possible alt design would be having the kernel responsible for making a TLS image copy for main thread & setting thread ptr to pt to it.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @oshepherd
That is what Sortix does. It also loads a master copy that can be used for new threads.
1 reply 0 retweets 0 likes -
__thread int errno; is online the instant _start is run
1 reply 0 retweets 0 likes -
Replying to @sortiecat @oshepherd
This is problematic for dynamic linking because the kernel won't know how much TLS space libraries need (assuming userspace ldso).
1 reply 0 retweets 0 likes -
Replying to @RichFelker @oshepherd
I'm yet to look into how dynamic link TLS works. If the dynamic linker uses static TLS, maybe it can upgrade the process to dynamic TLS.
1 reply 0 retweets 0 likes -
Replying to @sortiecat @oshepherd
Main program refs to TLS in DT_NEEDED libs are accessed at a ldso-time constant (can't vary per thread) offset from thread pointer.
1 reply 0 retweets 0 likes -
This requires a contiguous VA range whose size is sum of all library TLS sizes.
1 reply 0 retweets 0 likes -
Actual dynamic TLS access goes thru a function call so you can make the lookup as complex as you want, if you're happy paying.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @oshepherd
Ah so it's not a nice constant time memory access relative to the segment. OK, I start to see how this could work.
1 reply 0 retweets 0 likes
Yes. The offset is assigned by ldso and stored with GOT. Then the program just loads the offset from GOT and applies it.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.