On Mon, 3 Jun 2024, Tim Düsterhus wrote:
> 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?
It's for that, but also for path/branch analysis, as I just wrote above.
Having an EXIT opcode, instead of a function call is a clean indicator
that a path (and branch) ends here.
With a function call, I have no idea about whether a path ends there.
> > 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.
>
> 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.
Yes, but functions that call exit are not required to have the 'never'
return type, so that's not useful.
> > > > 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()?
It's not important for normal functionality as the execution still ends
there. It's useful for *testing* as I said before.
>
> Best regards
> Tim Düsterhus
>
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @[email protected] @[email protected]