Re: Transition path for removing lazy init of thread pointer

[Rich Felker <dalias@aerifal.cx>]

On Tue, Mar 25, 2014 at 12:01:45AM +0000, Laurent Bercot wrote:
> >Static linked non threaded programs sounds like a good target.
> 
>  +1.
>  Most of my userspace is made of statically linked, non-threaded
> programs, and I would love if musl was optimal for it.
>  Also, what is the mandatory first syscall on startup ? With
> musl-0.9.15, on kernel 3.2.something, there is no syscall at all
> (except execve(), of course) when starting a non-threaded program.

The mandatory syscall is set_thread_area or equivalent, e.g.
arch_prctl on x86_64. It's there because most archs need a syscall to
set the thread pointer used for accessing TLS. Even in single-threaded
programs, there are reasons one may want to have it.

The big reason is that, on most archs, stack protector's canary value
is stored at a fixed offset from the thread pointer rather than in a
global, so stack protector can't work without the thread pointer being
initialized. Up to now we've tried to detect whether stack protector
is used based on symbol references to __stack_chk_fail, but this check
gives a false negative (and thus crashing programs) if gcc optimizes
out the check to __stack_chk_fail but not the load of the canary, e.g.
in the program: int main() { exit(0); }

The other main reason is that lazy initialization is a lot more
expensive at runtime. All sorts of functions that need the thread
pointer (mainly synchronization primitives, like pthread_mutex_lock
when working with a recursive, error-checking, or robust mutex)
previously had to call a fairly heavy pthread_self() function that
performed the lazy initialization. Now they can just use an inline
implementation (usually asm) that obtains the thread pointer, and
for some functions having this inline means they're leaf functions and
the compiler can eliminate a lot of ugly prologue/epilogue/spilling
needed for non-leaf functions.

So despite always initializing the thread pointer kinda looking like
"bloat" from a minimal-program standpoint, it's really a major step
forward in debloating and simplifying lots of code.

Rich