Thanks for confirming Ian, this is very helpful. I agree with the implication that hacking Go on x86 to avoid TLS would not be a productive use of time compared to adding TLS support to the operating system.
Thanks again. On Sat, Aug 1, 2020 at 6:27 PM Ian Lance Taylor <i...@golang.org> wrote: > On Sat, Aug 1, 2020 at 2:46 PM <evan.mesterh...@gmail.com> wrote: > > > > You're right - after re-reading this I realize I could have been more > specific. > > > > I am working with a custom OS kernel that supports a subset of Linux > syscalls. However, it does not support TLS, which on i386 I believe > typically requires OS support to set up and restore the GDT and %gs segment > register between context switches. > > > > My understanding is that TLS using segment registers on i386 is largely > a speed and syntax optimization, but that thread specific data can be > managed without it (see glibc's pthread_setspecific() api). I am currently > building C programs for this OS by compiling for Linux / i386 using > uClibc-ng configured to disable TLS. I'm wondering if there is a similar > configuration option to build Go programs without TLS so that I can run > them on my OS. > > > > Please let me know if I can clarify anything further. > > While technically it might be possible to use something like > pthread_setspecific to handle Go's needs, 1) there is no support for > that in the current toolchain; 2) the execution time cost would be > significant. On x86 Go currently stores the stack guard in an offset > from the TLS segment register, and it checks that value at the entry > to (almost) every function. Requiring some sort of function call > would be a big slowdown at every function call. Also, come to think > of it, I'm not sure how to implement it; even pthread_setspecific > relies on TLS. > > One option would be to change Go on x86 to store the required > information in a register. That is how it works on some other > processors, so it would be feasible, but not at all simple. And you > would be using a custom port of Go that would not interoperate with > standard Go. > > Ian > -- Evan Mesterhazy evan.mesterh...@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN2qZSPFhR-RW3_bvGfnr-Lzdd2QDDiMn6W3ZRb-5_B0JDvYQw%40mail.gmail.com.
