--enable-stack-protector for glibc, v2, now with sparc.

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

This is version 2 of the stack-protected glibc patch, incorporating all review
comments (unless I missed some) and adding several changes brought to light by a
sparc32/sparc64 test cycle.  (Because it is my second posting of the series,
overconfidence will surely lead me to make some catastrophic error.  Apologies in
advance if merely reading this causes your computer to catch fire.)

Still no changelog citing bug 7065: I'm not confident enough that things won't
change.

It's not rebased and is still against glibc head as of a few days 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
--without-stack-protector
--enable-stack-protector=no

Tested with --enable-stack-protector, --enable-stack-protector=strong and
--enable-stack-protector=all on sparc32 and sparc64 (the machines were too
slow to want to do a fuller test cycle like the one above, and --enable-omitfp
does nothing on sparc anyway, IIRC).  No failures are observed that are not
also observed on an unpatched glibc with the same flag combinations, other
than localplt (due to the new __stack_chk_fail PLT, which I'd suggest is
desirable: it seems like something people might reasonably want to interpose,
and interposing it will have no performance implications).


Overview of changes in this posting:

 - Dropped the __stack_chk_fail() changes in their entirety: the bug they were
   working around was actually a problem with the stack protector interfering
   with the rtld mapfile computation, now fixed properly.

 - Ported to SPARC/SPARC64 (because I have access to the hardware and it was
   certain that porting it to more than one architecture would comb out
   problems, which it did, and because every time the tree is broken for davem,
   a fairy dies).

 - A new patch (patch 4) to deal with problems with TLS initialization in
   statically linked binaries.  This one is definitely an efficiency loss for
   such binaries but almost certainly nobody will ever notice or care: the
   alternatives are (to me, anyway), less palatable: see the patch.

 - memcpy() is stack-protected now.

Remaining mysteries:

 - In patch 13, I have no understanding of why __pthread_mutex_unlock_usercnt()
   and __pthread_mutex_cond_lock_adjust() are special: yes, they're called
   directly from assembler, but that shouldn't be a problem: -fstack-protector
   doesn't change the function-call ABI!  Nonetheless, it *is* a problem, and
   this is definitely necessary.  I just don't know what *else* might be
   necessary.  It is almost certain that this sort of thing will be the primary
   problem when making other arches happy with this change (it was the only real
   thing I had to do with sparc, in patch 14, -fno-sparc-protecting the
   sigreturn handler, and just as with the pthread functions I don't really know
   why -- but it is clearly necessary.)

   It *is* clear why we have to -fno-stack-protect setjmp/sigjmp.c: the thing is
   *sibcalled* from assembler, and the assembler has pre-built a stack frame,
   complete with lack of canary, so setjmp/sigjmp.c had better not introduce
   one.  (Even in the absence of local variables, -fstack-protector-all will add
   a canary to the lone function in that file.)