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