uclibc's nptl fails to build for arm with gcc-4.8 -fstack-check

[Rich Felker]

On Sat, Dec 27, 2014 at 03:51:46PM -0500, Anthony G. Basile wrote:
> Hi everyone,
> 
> I hit a bug in all versions of uclibc when building for TARGET=arm
> using gcc-4.8.3 with -fstack-check. This is a new option introduced
> in gcc-4.8 which checks that you don't go past the boundary of the
> stack in a *multithreaded* environment. In a single threaded
> environment -fstack-protector and friends is sufficient.

This description of -fstack-check is incorrect. It has nothing to do
with stack protector (ssp), which is for detecting buffer overflows in
stack-based buffers. -fstack-check has been around much longer than
since 4.8, and is for detecting stack overflow, not buffer overflow.
The documentation text about it only being needed in multithreaded
code is utterly wrong. It's always needed in code that might
stack-overflow with large automatic objects or alloca. Using
-fstack-check causes the compiler to (depending on the mode) either
compare against a known stack limit, or sequentially write to each new
stack page when allocating an object on the stack so that "stepping
over" the guard page(s) is not possible.

> This bug
> only affects arm as far as I can tell, and I had no problems with
> amd64, x86, mips or ppc. I did not test other arches.

Do you have a reason to believe -fstack-check is valuable in libc? It
should only be useful for code that has large automatic-storage
objects, which libc should not do (but I can't tell you for sure that
uclibc doesn't do that).

Rich