Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 16 Oct 2012 23:27:56 +0200
From: boris brezillon <b.brezillon.musl@...il.com>
To: musl@...ts.openwall.com
Subject: Re: TLS (thread-local storage) support

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@...il.com>:
> 2012/10/5 Rich Felker <dalias@...ifal.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...

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.