Initialize the stack guard earlier when linking statically [BZ #7065]

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.

In static appliations, __libc_setup_tls performs the TCB setup and TLS
initialization, so this commit arranges for it to be called early and
unconditionally.  The call (and the stack guard initialization) is
before 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 __libc_setup_tls (though if stack-protection is
enabled we still have to avoid calling functions that are not
stack-protected at this stage).

0 files changed, 0 insertions, 0 deletions