On Fri, Jan 05, 2018 at 01:10:21PM +0100, Florian Weimer wrote:
On 01/05/2018 12:41 PM, Mark Wielaard wrote:
>On Thu, Jan 04, 2018 at 09:36:27PM -0800, John Reiser wrote:
>>2) The explicit write by the stack probe can mask a memcheck(valgrind)
>> violation, at least until memcheck groks the probe.
>
>That should not be true. The probe is done after the stack pointer is
>lowered, so memcheck/valgrind knows that memory is used. If the probe
>is done below the actual stack pointer that would be a bug in the gcc
>-fstack-protector implementation. Please do report such issues when you
>encounter them. There were indeed such bugs in the past on some
>architectures (especially in combination with no-return functions),
>but I believe they have all been fixed now.
The generic -fstack-clash-protection in GCC has this problem, which
is why we can't use it and have to disable it on architectures where
there is no support, which currently includes armhfp. (For aarch64,
we still carry our own patch, and may have to continue doing that
even after switching to GCC 8.)
I noticed as a side effect of compiling GCC for riscv64 that RISC-V's
GCC doesn't support -fstack-clash-protection. Do you know what is
involved to add it? From a naive point of view I don't understand why
this feature depends on architecture at all.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW