[12/12] Avoid stack-protecting certain functions called from assembly.

  From: Nick Alcock <nick.alcock@oracle.com>

This is the problematic part.  Without -fno-stack-protector on these two
files, or more specifically on __pthread_mutex_cond_lock_adjust() and
__pthread_mutex_unlock_usercnt(), nptl/tst-cond24 and nptl/tst-cond25
receive a NULL mutex at unlock time and segfault.  However... I don't
understand why.  It is the callee's responsibility both to add the stack
canary and to initialize it, just like any other local variable.
It has to be, or the ABI for stack-protected code would be incompatible
with that for non-protected code.  But the fact remains that
sysdeps/unix/sysv/linux/i386/pthread_cond_timedwait.S both explicitly
mentions the stack frame layout and calls this function, and this call
goes wrong if we stack-protect it.

Looking at this, I'm now wondering how many other places GCC does calls
into C from assembler that break the rules in the same way. It can't be
all of them, or nothing would work -- but what about
sysdeps/x86_64/setjmp.S, which sibcalls into setjmp/sigjmp.c?  This
works and does not appear to need any -fstack-protector of any kind
at all -- but it also has no local variables, so I might be escaping by
luck rather than judgement...

So this is somewhere where I need someone to tell me what's special about
sysdeps/unix/sysv/linux/i386/pthread_cond_timedwait.S (and in particular
special about priority-inheritance mutexes: everything else works),
before I can be confident that this is even remotely the right thing to
do.
---
 nptl/Makefile | 4 ++++
 1 file changed, 4 insertions(+)