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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
