[PATCH 02/15] Initialize the stack guard earlier when linking statically.

[Florian Weimer]

On 12/19/2016 12:15 PM, Nix wrote:
> From: Nick Alcock <nick.alcock@oracle.com>
>
> The address of the stack canary is stored in a per-thread variable,
> which means that we must ensure that the TLS area is intialized before
> calling any -fstack-protector'ed functions.  For dynamically linked
> applications, we ensure this (in a later patch) by disabling
> -fstack-protector for the whole dynamic linker, but for static
> applications the AT_ENTRY address is called directly by the kernel, so
> we must deal with the problem differently.
>
> So split out the part of pthread initialization that sets up the TCB
> (and, more generally, the TLS area) into a separate function (twice --
> there is one implementation in libpthread.a, and another outside it for
> programs that do not link with libpthread), then call it at
> initialization time.  Call that, and move the stack guard initialization
> above the DL_SYSDEP_OSCHECK hook, which if set will probably call
> functions which are stack-protected (it does on Linux and NaCL too).
> We also move apply_irel() up, so that we can still safely call functions
> that require ifuncs while in __pthread_initialize_tcb_internal()
> (though if stack-protection is enabled we still have to avoid calling
> functions that are not stack-protected at this stage).

I'm changing this to call __libc_setup_tls directly.  This functions is 
in csu/ and thus automatically exempted from stack protection.  There is 
no need to go indirectly through a definition in nptl/.

(The old approach stems from the days where TLS was optional.)

Florian