Re: Really enable -fstack-clash-protection on armhf/armel?

On 24.11.23 07:19, Emanuele Rocca wrote:
> Hello!
> 
> On 2023-11-24 01:34, Guillem Jover wrote:
>> According to https://bugs.debian.org/918914#73 there were no pending
>> toolchain issues related to this.
> 
> That is correct. The GCC maintainers at Arm confirm that
> stack-clash-protection is supported on 32 bit too.

yes, but it's a different implementation, that apparently breaks a few 
more things than on the other architectures where it is enabled.
> 
> In case there are any bugs, which is of course possible, please file
> them and add debian-arm@ to X-Debbugs-CC.

No, I will not do that.  Sorry, but the task of the porters it NOT to 
put this kind of work on the shoulders on others, but to do this 
analysis themself.  You seem to rely on every other package maintainer 
to figure out these issues on their own. Please don't do that.

Debian is the first distro to turn this on on armhf, but didn't do any 
checks or test rebuilds before turning this on.

> So far I'm only aware of an issue with plplot, which turned out to be an
> actual bug in the software that stack-clash-protection helped uncover:
> https://bugs.debian.org/1055228#24

I filed now
https://bugs.launchpad.net/ubuntu/+source/libselinux/+bug/2044506
to collect some information what Ubuntu apparently hit.

A major problem will be valgrind stopping to work, causing issues in the 
test suites of other packages.

Also after rebuilding libxml2, libarchive, gnutls28, libselinux without 
this flag on armhf, issues go away again.  I'm not directly working on 
these, so can't give more information.

Matthias