Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Oct 2012 01:16:43 +0200
From: boris brezillon <>
Subject: Re: TLS (thread-local storage) support

2012/10/17 Szabolcs Nagy <>:
> * boris brezillon <> [2012-10-16 23:47:52 +0200]:
>> > There's at least one thing (maybe more) missing for go support with
>> > musl : gcc 'split-stack' support (see and
>> >
>> >
> why does go need support from libc?

You're right:
1) I was talking about gccgo but I realized there's another compiler
(gc go) which does not rely on gcc at all.
2) split stack is not mandatory for gccgo (see libgo/ in
gcc sources)

But it's still possible to enable split-stack and in this case go
runtime relies on some libc functions (see libgcc/generic-morestack*).

> it has its own runtime and libraries on raw syscalls
>> 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).
> what does a no_split_stack function do when it runs out of stack?


no_split_stack attribute is used for leaf functions or functions call
tree where the maximum stack size never exceed the reserved space for
extra stack chunk allocation (I don't remember the exact value).
> most functions in musl may be run before pthread_self_init
> (it runs on demand when a pthread function is used)
This can be done during dynamic linking process (by checking the split
stack note).
> what's the use of split stack if some functions may not work with it?
Only the explicitly specified functions (no_split_stack attribute)
won't include the split stack prolog.
This is the developer's responsability to carefully choose which one
to tag as 'no_split_stack'.

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.