On Tue, Mar 03, 2026 at 10:09:36AM +0100, Florian Weimer wrote: > * Jakub Jelinek: > > > Functionally, I think whether we do an 8-bit or 32-bit or 64-bit > > or with 0 constant doesn't matter, we don't modify any values on the > > stack, just pretend to modify it. The 8-bit and 32-bit ors > > are 1-byte shorter though than 64-bit one. How the 3 behave > > performance-wise is unknown, if the particular probed spot on the > > stack hasn't been stored/read for a while and won't be for a while, > > then I'd think it shouldn't matter, dunno if there can be store > > forwarding effects if it has been e.g. written or read very recently > > by some other function as say 32-bit access and now is 8-bit. The > > access after the probe (if it happens soon enough) should be in valid > > programs a store (and again, dunno if there can be issues if the > > sizes are different). > > I don't see a discussion in the code why a read-modify-write operation > is used for probing. Maybe because a plain load would need an extra > register? And a plain store could result in a valgrind false positive? > But maybe we could use CMPL? The register version is one byte shorter > than ORB, too. > > I think for -fstack-check, in may be desirable to trigger copy-on-write > on some systems, but for -fstack-clash-protection, that does not seem > necessary (no proactive triggering of stack overflow traps needed).
https://gcc.gnu.org/legacy-ml/gcc-patches/2017-07/msg00556.html talks about the possibility of using testb (but dunno if that would be for -fstack-clash-protection only). Using testb instead of orb/orl/orq won't detect the case when we somehow bypass the guard page below stack (if there is one) and reach a read-only mapped page, but maybe that is a non-issue as there should be always a guard page. Anyway, wonder if it isn't too late for such changes in GCC 16, whether we just shouldn't change Intel syntax to match AT&T for now and reconsider early in stage1. Jakub
