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: @derickr@phpc.social @xdebug@phpc.social
