Re: TLS (thread-local storage) support

[orc <orc@sibserver.ru>]

On Tue, 16 Oct 2012 23:47:52 +0200
boris brezillon <b.brezillon.musl@gmail.com> wrote:

> 2012/10/16 boris brezillon <b.brezillon.musl@gmail.com>:
> > Hi,
> >
> > First I'd like to thank Rich for adding TLS support (I started to
> > work on it a few weeks ago but never had time to finish it).
> >
> > 2012/10/6 Daniel Cegiełka <daniel.cegielka@gmail.com>:
> >> 2012/10/5 Rich Felker <dalias@aerifal.cx>:
> >>> On Thu, Oct 04, 2012 at 11:29:11PM +0200, Daniel Cegiełka wrote:
> >>>> great news! Finally able to compile Go (lang)...
> >>>
> >>> Did Go fail with gcc's emulated TLS in libgcc?
> >>
> >> I tested Go with sabotage (with fresh musl). I'll try to do it
> >> again... gcc in sabotage was compiled without support for TLS, so
> >> I didn't expect that it will be successful:
> >>
> >> https://github.com/rofl0r/sabotage/blob/master/pkg/gcc4
> >>
> > There's at least one thing (maybe more) missing for go support with
> > musl : gcc 'split-stack' support (see http://blog.nella.org/?p=849
> > and http://gcc.gnu.org/wiki/SplitStacks).
> >
> > I'm also interested in split stack support in musl but for other
> > reasons (thread and coroutine stack automatic expansion).
> >
> > For x86/x86_64 split stack is implemented using a field inside the
> > pthread struct which is accessed via %fs (or %gs for x86_64) and an
> > offset.
> >
> > Currently this offset is defined at 0x30 (0x70 for x86_64) by the
> > TARGET_THREAD_SPLIT_STACK_OFFSET but only if
> > TARGET_LIBC_PROVIDES_SSP is defined (see gcc/config/i386/gnu-user.h
> > or gcc/config/i386/gnu-user64.h).
> >
> > As far as I know musl does not support stack protection, but we
> > could at least patch gcc to define TARGET_THREAD_SPLIT_STACK_OFFSET
> > when using musl.
> >
> > We also need to reserve a field in the musl pthread struct. There
> > are currently two fields named 'unused1' and 'unused2' but I'm not
> > sure they're really unused in every supported arch.
> >
> >
> > BTW, I'd like to work on a more integrated support of split stack
> > in MUSL :
> >
> > 1) support in dynamic linker (see the last point of
> > http://gcc.gnu.org/wiki/SplitStacks) : check split stack notes in
> > shared libs (and program ?)
> >
> > 2) support in thread implementation : currently when a thread is
> > created the stack limit is set afterward (see
> > https://github.com/mirrors/gcc/blob/master/libgcc/generic-morestack-thread.c
> > and
> > https://github.com/mirrors/gcc/blob/master/libgcc/config/i386/morestack.S)
> > and the stack size is supposed to be 16K (which is the minimum
> > stack size). This means we may reallocate a new stack chunk even if
> > the previous one (the first one) is not fully used. If stack limit
> > is set by thread implementation, this can be set appropriately
> > according to the stack size defined by the thread creator.
> >
> > 3) more optimizations I haven't thought about yet...
> >
> 4) Compile musl with '-fsplit-stack' and add no_split_stack attribute
> to appropriate functions (at least all functions called before
> pthread_self_init because %gs or %fs register is unusable before this
> call).
> 
> 5) set main thread stack limit to 0 (pthread_self_init) : the main
> thread stack grow is handled by the kernel.
> 
> 6) add no-split-stack note to every asm file.
Why anything works only after putting a weak spikes that break after a
slight touch?

> 
> 7) make split stack support optional (either by checking the
> -fsplit-stack option in CFLAGS or with a specific option :
> --enable-split-stack) : split stack adds overhead to every functions
> (except for those with the 'no_split_stack' attribute).
> 
> > Do you have any concern about adding those features in musl ?
> >
> > Let me know if you see other issues I haven't noticed.
> >
> >
> > Regards,
> >
> > Boris

After reading whole thread I agree with Rich that this one is not only
hard to implement, but completely useless. From other point of view:
people expect from musl an easy to read and understand code, that not
only works, but is easy to understand, modify, debug and build. Why
extend it with features not even related to libc? (It is mostly a hack
from gcc-binutils again?)
Not only saying a word about people that use (or will use) other
compilers and linkers.