Is it possible to build without TLS (thread local storage)?

[evan.me...@gmail.com]

Hi all,

Is it possible to build pure Go (no cgo) programs targeting i386 without TLS support? From reviewing the compiler flags and the compiler build options it looks like this isn't possible, but I am hoping someone with knowledge on the matter can comment definitively.

Thanks,

Evan

[Jan Mercl]

Not sure I understand correctly, but TLS is usually provided on some level by the kernel of the specific OS. Another level is TLS as in, for example pthreads.

The Go runtime probably uses one or the other additionally to goroutine local storage.

Can you please clarify?

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/630327db-52b6-47e1-b423-711719740663o%40googlegroups.com.

[evan.me...@gmail.com]

Hi Jan,

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.

Thanks!

On Saturday, August 1, 2020 at 2:23:13 PM UTC-4, Jan Mercl wrote:

Not sure I understand correctly, but TLS is usually provided on some level by the kernel of the specific OS. Another level is TLS as in, for example pthreads.

The Go runtime probably uses one or the other additionally to goroutine local storage.

Can you please clarify?

On Sat, Aug 1, 2020, 20:08 <evan.me...@gmail.com> wrote:

Hi all,

Is it possible to build pure Go (no cgo) programs targeting i386 without TLS support? From reviewing the compiler flags and the compiler build options it looks like this isn't possible, but I am hoping someone with knowledge on the matter can comment definitively.

Thanks,

Evan

--
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 golan...@googlegroups.com.

[Ian Lance Taylor]

On Sat, Aug 1, 2020 at 2:46 PM <evan.me...@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]

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.

--

Evan Mesterhazy

evan.me...@gmail.com