On 3/3/2026 2:27 AM, Jakub Jelinek wrote:
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.
There should always be a guard page and we're never supposed to be able
to skip over the guard so it shouldn't matter. I do know a way to skip
the guard, but it's relatively obscure.
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.
I'd think this kind of change should be safe at this point.
jeff
