On 3/3/2026 2:09 AM, 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.
It's gotten fuzzy, but my recollection is that there wasn't anything
special about the memory operation. We just needed to trigger the fault
in the kernel to either extend the stack or signal user space that there
wasn't any more address space available.
So it shouldn't matter if it's a RMW. It shouldn't even matter if it's
just a read. So testb should be sufficient, or other variants folks
have discussed.
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).
And given we built on top of -fstack-check, the probing behavior could
well be defined by -fstack-check right now, but it doesn't have to stay
that way.
jeff
