--enable-stack-protector for glibc.

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

So this is the provisional "stack-protect glibc" patch, a version of which has
been running for many, many years on my (x86-32 Geode) firewall.  No changelog
yet, but I'll write one soonish.  (When I do, it'll cite glibc bug 7065.  Bug
7066, a buffer overrun in strtold(), was uncovered during the initial
development of this patch, many years ago.)

It's against glibc head as of a few days ago, a5df3210a641c17.

I've gone through it and dropped things that don't seem to have any
justification nor affect testsuite results.  Some of the things thus dropped may
in fact be important for proper functioning of things like error messages from
statically linked programs when running against a kernel too old for the glibc:
I haven't retested that case, but it is plausible.  (I'll test that case at some
point in the next few days, but after many dozens of 64- and 32-bit x86 glibc
build-and-tests with every combination of
--enable-stack-protector={no,yes,all,strong} / --enable-omitfp /
--enable-stackguard-randomization I had frankly had enough of that for now!)

The testsuite passes with every combination of those flags (other than various
combinations with --enable-stack-protector=no, that seemed pointless to test):
no failures are observed with it that are not also observed on an unpatched
glibc with the same flag combinations.  However, until last night two things
were failing: I figured out how to stop them, but I don't understand why this
patch works and why, if it works, many others aren't needed (see the last patch
in the series).


I have not even considered investigating the performance of this.  Suffice to
say that with everything *but* glibc stack-protected on many distros, and with
perforamnce appearing quite acceptable to me on a 32-bit 500MHz embedded
processor, the performance implications of this patch do not appear to be
catastrophic. It's probably the same as the stack-protector always is: a few
percent.

The patches themselves have my work address on them because I just spent
a couple of work days on them.