--enable-stack-protector for glibc, v5

[Nix <nix at esperi dot org dot uk>]

This is version 5 of the stack-protected glibc patch, incorporating all review
comments to date (unless I missed some), and finally clearing up the long-
standing mystery surrounding __pthread_mutex_unlock_usercnt() et al.

It's not rebased and is still against glibc head as of a few weeks ago,
a5df3210a641c17.

Tested with these flag combinations on {i686,x86_64)-pc-linux-gnu:

--enable-omitfp --enable-stack-protector=all
--enable-stack-protector
--enable-stack-protector=strong
--enable-stack-protector=all
--enable-stackguard-randomization --enable-stack-protector=all
--enable-omitfp --enable-stackguard-randomization --enable-stack-protector
--enable-omitfp --enable-stackguard-randomization --enable-stack-protector=strong
--enable-omitfp --enable-stackguard-randomization --enable-stack-protector=all
--disable-stack-protector
--enable-stack-protector=no

Tested with with these flag combinations on sparc{32,64}-pc-linux-gnu:

--enable-stack-protector
--enable-stack-protector=strong
--enable-stackguard-randomization --enable-stack-protector=strong
--enable-stackguard-randomization --enable-stack-protector=all
--disable-stack-protector

Tested with these flag combinations on armv7l-unknown-linux-gnueabihf (it
happened to have GCC 4.8, so -strong wasn't available):

--enable-stackguard-randomization --enable-stack-protector
--enable-stackguard-randomization --enable-stack-protector=all --enable-omitfp
--disable-stack-protector

No failures are observed that are not also observed on an unpatched glibc with
the same flag combinations. (There is one intermittent failure on arm: a
segfault from nptl/tst-cancelx17. However, it intermittently fails for me on the
unpatched baseline too, so I'm not making it any worse!)

On the copyright assignment front, I am informed that Oracle has a blanket
assignment on file for glibc work, so I don't need to do anything. (Patch 11 is
in Adhemerval's name, but obviously there's no assignment problem there either.)

The only remaining question I really have is what to do instead of patch 14,
which I really do expect to be rejected.  Another configure argument to set the
stack-protection level of externally-facing components, perhaps, or simply a
wiring-in that if --enable-stack-protector is not passed, that -fstack-protector
is passed in for these external components anyway?  What I do think is that the
level set via --enable-stack-protector should be a minimum: that libresolv, nscd
et al should never be protected *less* than libc.so and the rest are.  Patch 14
was a nice simple way to do that, but it is probably *too* simple...

Overview of changes in this posting:

 - Do not call __stack_chk_fail through the PLT for calls within libc itself,
   and calls within libc_nonshared.a as well.

 - Do not build __stack_chk_fail or __stack_chk_fail_local with stack-protection
   to avoid the (very unlikely) possibility of recursion.

 - Fix the comment describing of inhibit_stack_protector, which was
   incomprehensible.

 - Solve the great __pthread_mutex_unlock_usercnt() mystery: see patch N in the
   series.  Stack protection wasn't breaking anything, it was just legitimately
   clobbering a register it was allowed to clobber, and the i386 assembly
   implementation of pthread_cond_wait() et al were assuming it was not
   clobbered across calls.  All of the non-assembly parts of threading other
   than ifunc resolvers and a one-line initialization function in nptl-init.c
   are now stack-protected.

 - Stack-protect brk() and sbrk() in the shared library: they only need to be
   unprotected in the three varieties of static libc, where they are used in
   early init.

 - Reshuffle the series so that it is always compilable (I think).  (This was
   once true, but commits had crept in after the commit that wired up the
   --enable-stack-protector configure flag into a -fstack-protector compiler
   flag.)

 - Changelogs for everything.

Remaining mysteries:

 - None!