Hi
On 5/29/24 20:05, Derick Rethans wrote:
For each op_array, Xdebug tries to figure out every possible path by
following jumps. Certain opcodes, such as GENERATOR_RETURN, THROW,
RETURN, and EXIT [1] are considered as an exit point out of the
function. A path ends there.
You linked to a code_coverage.c. Is this information just used for code
coverage analysis to indicate that unreachable code is unreachable and
thus uncoverable or is there more to this?
If there is a function call to a function with a 'never' return type,
then that function will potentially throw, or exit.
But that's not relevant for the analysis, as these userland functions
will have their own oparrays with their entry and exit points.
I can't through this mechanism know when an *internal* function does
something similar, as it looks like just a normal function call (unless
I hard code the check for a call to 'exit').
The compiler has the function table available. It is used to optimize
specific functions into dedicated Opcodes. Thus you should be able to
look up the function within the function table and then check its return
type.
[1]
https://github.com/xdebug/xdebug/blob/master/src/coverage/code_coverage.c#L348
It also breaks my "do tasks on ZEND_EXIT" with the profiler. It is
used to always write the closing profiling footer to the files.
Without me being able to overload thati opcode, data would not be
complete. I even have two bugs (with tests) for this:
- https://bugs.xdebug.org/68
- https://bugs.xdebug.org/631
Likewise, how is ZEND_EXIT special here? How does it work differently than a
script that runs to completion without calling exit(); or a script that fails,
e.g. due to an uncaught exception or due to reaching the memory limit?
I overload EXIT so that I can flush the profile file before the script
actually fully ends. This is useful for testing through phpt tests. It
looks like I might be able to use existing function observers for this,
but I haven't fully made that work yet.
Why does the EXIT opcode need to be special-cased here? What if a script
dies due to an uncaught Exception, due to exceeding the memory limit, or
simply terminates by successfully running until the finish, without
explicitly calling exit()?
Best regards
Tim Düsterhus
