On 2025-04-09 08:05, Guillem Jover wrote: > On Wed, 2025-04-09 at 18:05:21 +0100, Andrew Sayers wrote: > > gcc lets you set `-fstack-clash-protection` on Pi armhf bookworm, > > but doing so causes valgrind errors even in trivial programs: > > > $ gcc -fstack-clash-protection -x c - <<EOF > > void empty_function() {} > > int main() { > > empty_function(); > > return 0; > > } > > EOF > > $ valgrind ./a.out > > ==19138== Memcheck, a memory error detector > > ==19138== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > > ==19138== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info > > ==19138== Command: ./a.out > > ==19138== > > ==19138== Invalid write of size 4 > > ==19138== at 0x1041C: main (in /home/andrew/a.out) > > ==19138== Address 0x7db5f2a0 is on thread 1's stack > > ==19138== 8 bytes below stack pointer [...] > I cannot reproduce this in a Debian armhf sid chroot, and I assume > this would have been reported earlier if it had affected Debian there, > even on bookworm. In Debian we added a suppression as a workaround, which is why on sid the error reported by Andrew cannot be reproduced. Raspberry Pi OS may want to do the same. https://sources.debian.org/src/valgrind/1%3A3.24.0-2/debian/supp/armhf-stackclash.supp/ The issue here is that valgrind upstream has not been updated to follow the latest (2018) Procedure Call Standard, which among other things allows writes below the stack pointer. I opened a bug in that regard and received no replies: https://bugs.kde.org/show_bug.cgi?id=479699 > > Please disable `-fstack-clash-protection` on Pi armhf (and Debian armhf if > > the issue can be replicated there). > > dpkg upstream has no knowledge or support for Raspberry Pi OS, and > thus it cannot be disabled for it. After Trixie I think we should disable it in Debian too. Although the suppression above works for some of the problems valgrind has on armhf, there is a trickier one. Certain programs built with stackclash cause valgrind to segfault, and this regularly causes confusion and quite a lot of unnecessary work. https://bugs.debian.org/1061496 is the relevant bug in the BTS. When we chose to turn stackclash on I thought the advantages would outweight the disadvantages, but I was wrong. I think we should reconsider the decision and re-enable stackclash on armhf only if valgrind upstream gets updated to properly support recent standards. On armel it does not really matter given that valgrind isn's supported at all there.
Attachment:
signature.asc
Description: PGP signature