Here's a thread from 2014 on how I optimized the libc for a minimal static link without complicating things too much http://forum.osdev.org/viewtopic.php?f=15&t=28339 …
-
-
Aha - so the kernel loads the program headers for static programs? libc then iterates them and locates TLS?
-
The program headers are part of one of the PT_LOAD maps since they're needed at runtime for various reasons including TLS.
-
Aha - did not know that. Feels a little dirty to me.
-
Looks like Sortix executables does happen to map the program headers as well, but I never use them, so that might just be a waste of memory.
End of conversation
New conversation -
-
-
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.
-
That is what Sortix does. It also loads a master copy that can be used for new threads.
-
__thread int errno; is online the instant _start is run
-
This is problematic for dynamic linking because the kernel won't know how much TLS space libraries need (assuming userspace ldso).
-
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.
-
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.
-
This requires a contiguous VA range whose size is sum of all library TLS sizes.
-
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.
- 2 more replies
New conversation -
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.