The aim of this PR is twofold:
- Reduce the number of highly similar TMP|VAR handlers
- Avoid ZVAL_DEREF in most of these cases
This is achieved by guaranteeing that all zend_compile_expr() calls, as well as
all other compile calls with BP_VAR_{R,IS}, will result in a TMP variable. This
implies that the result will not contain an IS_INDIRECT or IS_REFERENCE value,
which was mostly already the case, with two exceptions:
- Calls to return-by-reference functions. Because return-by-reference functions
are quite rare, this is solved by delegating the DEREF to the RETURN_BY_REF
handler, which will examine the stack to check whether the caller expects a
VAR or TMP to understand whether the DEREF is needed. Internal functions will
also need to adjust by calling the zend_return_unwrap_ref() function.
- By-reference assignments, including both $a = &$b, as well as $a = [&$b]. When
the result of these expressions is used in a BP_VAR_R context, the reference
is unwrapped via a ZEND_QM_ASSIGN opcode beforehand. This is exceptionally
rare.
Closes GH-20628
These are leftovers from the pre-PHP-7.0 era. This also implicitly solves
GH-20564 by not clearing exceptions before entering the autoloader.
Closes GH-20256
Fixes GH-20564
UNSET_OBJ et al. do not expect to find IS_UNDEF results for IS_INDIRECT vars. To
solve this, return IS_NULL from FETCH_OBJ_UNSET when properties are
uninitialized. Do the same for FETCH_STATIC_PROP_IS, as we're otherwise copying
IS_UNDEF into the VAR result, which is not a valid value for VAR.
Fixes OSS-Fuzz #429429090
Closes GH-19160
* Fix use-after-free in FE_FREE with GC interaction
When FE_FREE with ZEND_FREE_ON_RETURN frees the loop variable during
an early return from a foreach loop, the live range for the loop
variable was incorrectly extending past the FE_FREE to the normal
loop end. This caused GC to access the already-freed loop variable
when it ran after the RETURN opcode, resulting in use-after-free.
Fix by splitting the ZEND_LIVE_LOOP range when an FE_FREE with
ZEND_FREE_ON_RETURN is encountered:
- One range covers the early return path up to the FE_FREE
- A separate range covers the normal loop end FE_FREE
- Multiple early returns create multiple separate ranges
* Split the live-ranges of loop variables again
b0af9ac733 removed the live-range splitting of foreach variables, however it only added handling to ZEND_HANDLE_EXCEPTION.
This was sort-of elegant, until it was realized in 8258b7731b that it would leak the return variable, requiring some more special handling.
At some point we added live tmpvar rooting in 52cf7ab8a2, but this did not take into account already freed loop variables, which also might happen during ZEND_RETURN, which cannot be trivially accounted for, without even more complicated handling in zend_gc_*_tmpvars() functions.
This commit also proposes a simpler way of tracking the loop end in loopvar freeing ops: handle it directly during live range computation rather than during compilation, eliminating the need for opcache to handle it specifically.
Further, opcache was using live_ranges in its basic block computation in the past, which it no longer does. Thus this complication is no longer necessary and this approach should be actually simpler now.
Closes#20766.
Signed-off-by: Bob Weinand <bobwei9@hotmail.com>
---------
Signed-off-by: Bob Weinand <bobwei9@hotmail.com>
Co-authored-by: Gustavo Lopes <mail@geleia.net>
In this test, we will loop once, and then replace the object with an
instance that'll throw on property construction in Z_OBJPROP_P() in
the ZEND_FE_FETCH_RW VM handler.
Since at that point `pos >= fe_ht->nNumUsed`, we exit via
`fe_fetch_w_exit` without checking for an exception, causing incorrect
continuation of the code and an eventual assertion failure.
To solve this, we perform an exception check at the end of the
iteration. This should be sufficient to guarantee the exception is
checked in time as failure of get_properties() via Z_OBJPROP_P() will
always result in an empty hash table.
This should also be more efficient than the alternative fix that checks
for an exception right after Z_OBJPROP_P() as that would be executed at
each iteration.
Closes GH-20098.
This cache is implemented in two levels: A EG(callable_convert_cache) global
that maps zend_function pointers to a shared callable instance, and a
CALLABLE_CONVERT cache slot to remember the result of the hash table lookup.
Fixes GH-19754
Closes GH-19863
This happened implicitly in the past due to EX(opline) being used - or in the hybrid VM case, the implicit LOAD_OPLINE() happening as part of ZEND_VM_ENTER().
With 76d7c616bb opline is used standalone and the return value of zend_interrupt_helper_SPEC ignored. Make use of it...
Signed-off-by: Bob Weinand <bobwei9@hotmail.com>
The removal of empty lines and lines containing only semicolons moved the
offsets around. Remove just the standalone semicolons without removing entire
lines to keep both files in sync. This is also useful for IDE split view mode
even when not enabling `--with-lines`.
Introduce the TAILCALL VM, a more efficient variant of the CALL VM:
* Each opcode handler tailcalls the next opcode handler directly instead of
returning to the interpreter loop. This eliminates call and interpreter loop
overhead.
* Opcode handlers use the preserve_none calling convention to eliminate
register saving overhead.
* preserve_none uses non-volatile registers for its first arguments, so
execute_data and opline are usually kept in these registers and no code is
required to forward them to the next handlers.
Generated machine code is similar to a direct-threaded VM with register pinning,
like the HYBRID VM.
JIT+TAILCALL VM also benefits from this compared to JIT+CALL VM:
* JIT uses the registers of the execute_data and opline args as fixed regs,
eliminating the need to move them in prologue.
* Traces exit by tailcalling the next handler. No code is needed to forward
execute_data and opline.
* No register saving/restoring in epilogue/prologue.
The TAILCALL VM is used when the HYBRID VM is not supported, and the compiler
supports the musttail and preserve_none attributes: The HYBRID VM is used when
compiling with GCC, the TAILCALL VM when compiling with Clang>=19 on x86_64 or
aarch64, and the CALL VM otherwise.
This makes binaries built with Clang>=19 as fast as binaries built with GCC.
Before, these were considerably slower (by 2.8% to 44% depending on benchmark,
and by 5% to 77% before 76d7c616bb).
Closes GH-17849
Closes GH-18720
Having an empty result array is not a problem, because zend_hash_extend()
will initialize it. Except it does not when the number of elements to add
equals 0, which leaves the array uninitialized and therefore does not
set the packed flag, causing the assertion failure.
Technically, removing the assert would also work and save a check.
On the other hand, this check could also prevent some real work to be
done and should be relatively cheap as we already have to compute the
sum anyway.
Closes GH-19318.
When opcache is enabled, error handling is altered in the following ways:
* Errors emitted during compilation bypass the user-defined error handler
* Exceptions emitted during class linking are turned into fatal errors
Changes here make the behavior consistent regardless of opcache being enabled or
not:
* Errors emitted during compilation and class linking are always delayed and
handled after compilation or class linking. During handling, user-defined
error handlers are not bypassed. Fatal errors emitted during compilation or
class linking cause any delayed errors to be handled immediately (without
calling user-defined error handlers, as it would be unsafe).
* Exceptions thrown by user-defined error handlers when handling class linking
error are not promoted to fatal errors anymore and do not prevent linking.
Fixes GH-17422.
Closes GH-18541.
Closes GH-17627.
Co-authored-by: Tim Düsterhus <tim@bastelstu.be>
This reduces the chances of confusion between opcode handlers used by the
VM, and opcode handler functions used for tracing or debugging. Depending
on the VM, zend_vm_opcode_handler_t may not be a function. For instance in
the HYBRID VM this is a label pointer.
Closes GH-19006
* PHP-8.4:
Update NEWS for GH-19068
ext/gd: Drop useless and doubtful MSVC specific code (libgd/libgd@f1480ab)
Zend: fix undefined symbol 'execute_ex' on Windows ARM64 #19064; ext/gd: fix emmintrin.h not found on Windows ARM64
Registering the constant may happen under another name due to
lowercasing. This will cause the lookup to the constant to fail.
Instead of looking it up, just change the Zend API to return a pointer
instead.
Checking the non-exception path without arguments first, this avoids a redundant check in the case without arguments. The exception path may become more expensive, but we don't optimize for exception flow, rather we optimize for the happy flow. The other paths are unaffected.
Add recursion protection when emitting deprecation warnings for class
constants, since the deprecation message can come from an attribute that is
using the same constant for the message, or otherwise result in recursion.
But, internal constants are persisted, and thus cannot have recursion
protection. Otherwise, if a user error handler triggers bailout before the
recursion flag is removed then a subsequent request (e.g. with `--repeat 2`)
would start with that flag already applied. Internal constants can presumably
be trusted not to use deprecation messages that come from recursive attributes.
Fixes GH-18463
Fixes GH-17711
