Enable 64bit integer support on 32bit arch --enable-zend-int64 - #19079
Draft
marc-mabe wants to merge 22 commits into
Draft
Enable 64bit integer support on 32bit arch --enable-zend-int64#19079marc-mabe wants to merge 22 commits into
--enable-zend-int64#19079marc-mabe wants to merge 22 commits into
Conversation
Member
|
I think this should go through the RFC process. There have been suggestions to drop 32-bit support, so I'm sure at least some people would object to expanding support further. I could see this as an alternative to dropping 32-bit support iff we also dropped 4-byte zend_long support, as that would align 32 and 64-bit. |
Girgias
reviewed
Jul 9, 2025
Contributor
Author
|
I have fixed some cases which failed due to SIZEOF_SIZE_T != SIZEOF_ZEND_LONG, but there are probably more. Currently, the test state is as follows: |
Contributor
Author
Yes, of course. At the current state I want to get to know the work needed to be done and do some benchmarks. For dropping 32-bit support entirely it seems to be to early at least for WebAssembly + there might be people hoping for supporting older (in some cases not that old) systems - so I don't thing it would go through currently. |
marc-mabe
force-pushed
the
int64
branch
6 times, most recently
from
July 9, 2025 21:43
4fb8912 to
6b552c1
Compare
marc-mabe
force-pushed
the
int64
branch
2 times, most recently
from
July 13, 2025 20:22
e28b737 to
f41823a
Compare
marc-mabe
force-pushed
the
int64
branch
2 times, most recently
from
September 2, 2026 14:17
aa21436 to
f6c057a
Compare
marc-mabe
force-pushed
the
int64
branch
2 times, most recently
from
September 12, 2026 05:32
ed8bfa0 to
20c699a
Compare
The greatest length a string can have, exposed so that userland and the test suite can reason about the limit without hard coding the header size. ZSTR_MAX_LEN is SIZE_MAX - ZSTR_MAX_OVERHEAD and so exceeds ZEND_LONG_MAX wherever size_t is at least as wide as zend_long; registered unclamped it would land as a negative int. It is capped to ZEND_LONG_MAX instead, which is also the more accurate value: every userland string length travels through zend_long -- strlen()'s return value, string offsets and substr()'s arguments -- so a longer string could not report its own length. The constant therefore equals PHP_INT_MAX on every platform that ships today, including 32 bit, and only becomes a distinct value where zend_long is wider than size_t.
_zend_mm_alloc() verifies that adding the per allocation zend_mm_debug_info to the requested size does not overflow, but zend_mm_realloc_heap() and zend_mm_realloc_huge() perform the same addition without that check. In a debug build a request within a few bytes of SIZE_MAX therefore wraps to a tiny allocation while the caller believes it received the size it asked for, and then writes past the end of it. The only way to reach this from PHP is assigning to a string offset close to SIZE_MAX, which is possible solely where zend_long is wider than size_t and is refused before the reallocation by the following commit, so there is no test that can exercise it.
The allocator works in units of the platform word, not of zend_long. The two coincide everywhere except with ZEND_INT64 on a 32bit platform, where the page bitset became 64bit wide and every scan of it did 64bit arithmetic on 32bit registers. Type the bitset as size_t, move the two width checks it feeds onto SIZEOF_SIZE_T, and build its masks from zend_mm_bitset rather than from Z_UL()/Z_L(). heap->limit is a size_t as well and no longer takes a detour through zend_long to spell (size_t)-1. zend_mm_bitset_ntz() replaces the call to zend_ulong_ntz(), which is part of the zend_bitset family and typed for zend_ulong; a size_t bitset widened into it on every page scan. It carries the implementation and zend_mm_bitset_nts() is now ntz() of the complement, so the two cannot drift apart. The runtime sizeof() test inside the 8 byte branch of the fallback is gone; the enclosing #if already decides it.
The previous commit commented the whole optimisation out because it did not
work on i386 with a 64-bit zend_long. That switched it off on every platform,
including x86-64 and aarch64 where the sequences were always correct, so
narrow it down to what is actually broken.
The i386 sequences operate on 32 bits: addl/subl on the low half of the value
and jo on a 32-bit overflow flag. With a 64-bit zend_long that is wrong three
ways -- 2147483647 + 1 reports an overflow that did not happen, 4294967295 + 1
drops the carry and yields 0, and PHP_INT_MAX + 1 overflows unnoticed and
yields 9223372032559808512.
Increment and decrement gain a 64-bit sequence that carries across both halves
with adcl/sbbl, where the overflow flag of the second instruction is the one
that matters. Addition and subtraction keep the 32-bit sequence only: holding a
64-bit value needs a second scratch register, and inside execute_ex() %esi and
%edi are pinned as the VM's global register variables, leaving eax/ebx/ecx/edx.
Three "r" operands plus two clobbers cannot be allocated, and gcc loops in
register allocation rather than reporting it. Those two are served by the
__builtin_s{add,sub}ll_overflow() paths that follow.
int_overflow_64bit.phpt covers the increment and decrement boundaries, which
nothing exercised before.
The IR x86 backend emits 64bit integer instructions only when it is built for X64. On a 32bit target the 8 byte cases of the type dispatch are not compiled at all, so an 8 byte operand reaches the default label. In a debug build that is IR_ASSERT(0) and the process aborts; in a release build IR_ASSERT() expands to nothing and control falls through into the 1 byte case, which emits a byte sized instruction with the immediate masked to 0xff. The JIT would silently generate wrong code. Supporting this properly means adding 64bit arithmetic over register pairs to 21 emission paths in the x86 backend, which belongs upstream in IR rather than here. Until then refuse to enable the JIT, in the same place and shape as the existing Apple Silicon ZTS check. The condition is false wherever zend_long matches the platform word, so every shipping platform is unaffected.
zend_string_alloc() and zend_string_safe_alloc() add the header and the terminating NUL to the requested length without an overflow check, so a length above ZSTR_MAX_LEN wraps to a tiny allocation carrying a huge ZSTR_LEN. That bound has always been the callers' responsibility, but it was neither documented nor enforced anywhere. Assert it in the four allocators that take a length, making the contract executable in debug builds at no cost to release builds.
strncmp() and strncasecmp() pass $length straight into the size_t parameter of zend_binary_strncmp()/zend_binary_strncasecmp(). Where zend_long is wider than size_t the value is narrowed, so a length above SIZE_MAX compares fewer bytes than was asked for and reports equality for operands that differ further along: SIZE_MAX + 1 becomes 0 and SIZE_MAX + 3 becomes 2. Clamp to SIZE_MAX instead, as substr_compare() already does. Both comparators reduce the length to MIN(length, MIN(len1, len2)) internally, so every value at or above the operand lengths behaves alike and no new error is needed.
Runs the test suite on a 32bit build whose zend_long is 64bit, the configuration --enable-zend-int64 makes possible. The job mirrors LINUX_X32 and adds --enable-zend-int64. It builds with -mfpmath=sse. On i386 the x87 unit loads a 64bit integer exactly into an 80bit register, so (double) a * (double) b multiplies an operand that was never rounded to binary64 and the product differs from every 64bit platform in the last place. SSE math rounds the operand first and keeps the results identical. The x87 precision control word that zend_init_fpu() sets does not help here: it limits the mantissa of the arithmetic, not the exactness of the integer load. configure-x32 gained a cflags input rather than growing a second copy of the action; LINUX_X32 keeps its previous flags through the default.
The synthetic namespace bookkeeping keys a HashTable by the xmlNode it belongs to and casts the key back to a pointer when unlinking. Both directions went through a plain cast, which is a narrowing conversion where zend_long is wider than a pointer. Use ZEND_PTR_TO_ZEND_ULONG() and ZEND_ULONG_TO_PTR() instead. The low bit of the key stays available as the marker for the default namespace entry, as xmlNode is aligned well beyond two bytes.
The signal table keeps handlers in the zend_long payload of a zval while SIG_DFL, SIG_IGN and SIG_ERR are pointer constants. Converting between the two with a plain cast narrows where zend_long is wider than a pointer, and would turn SIG_ERR from -1 into its zero extended image. Use ZEND_PTR_TO_ZEND_LONG() and ZEND_LONG_TO_PTR() for those conversions and for the fault address in the siginfo array. LONG_CONST() did the same job for the constant registration and is replaced by it. php_signal() takes the SA_SIGINFO form of a handler, so handing it SIG_DFL still needs a detour over a data pointer to stay clear of -Wcast-function-type, but that one no longer passes through an integer.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR allows to use 64bit integers on 32bit platforms if compiled with
--enable-zend-int64--enable-zend-int64)PHP_SYS_SIZE = [4|8])Zend/tests/andtests/ext/The main part is that
ZEND_ENABLE_ZVAL_LONG64 1gets defined.