Re: Really enable -fstack-clash-protection on armhf/armel?
Hello,
Another Canonicaler chiming in, I was also involved with debugging this problem in Ubuntu.
I believe the most obvious issues we were having was the gsasl tests indirectly triggered
by gnutls28, and the unrar-free tests triggered by libarchive. Both of which do include
valgrind use.
In addition to flag being obviously incompatible with valgrind, it also caused issues
with gdb for me, and some segmentation faults in gsasl outside any debugging tools
(although I did not investigate these in much detail).
There are claims from upstream about the implementation on 32-bit arm being questionable,
and no other distros seem to ship it. I believe enabling this before more upstream work
to fix these issues would be unwise. Breaking valgrind and gdb is already problematic
enough by itself, let alone any previously unknown issues discovered entering uncharted
waters.
Mate Kukri
FTR there is no issue in Debian with any of the above in my tests.
Also the packages don't seem to use valgrind at any point: not when
building, not in the autopkgtests.
Full build logs including autopkgtest output here:
https://people.debian.org/~ema/armhf-stack-clash-protection/
What exactly did not work in Ubuntu and how? Perhaps there are
additional jobs running valgrind in CI that may explain the failures?
Thanks,
Emanuele
Reply to: