Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123495
Message-ID: <f3c4dcb0-e2e3-424e-94b8-c5a39fcc827c@bastelstu.be>
Date: Mon, 3 Jun 2024 19:38:34 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a
 standard function
To: Derick Rethans <derick@php.net>
Cc: Ilija Tovilo <tovilo.ilija@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <GUMp_LJKefk4aLz9P9MA-zonKuik6uUNWZTtOAx-IeIhjPFsgfT3HHECPpyGF_ujq-LxI6tzBxMYgL5CMVGRkyzxSugweKix_YUGo2rXnb4=@gpb.moe>
 <b2IQjZQlOsMoMuk9Jw5edeVfHqqbcWCQc6DQF5jKrRkGryVyvu6rC9sbSW2D-HK9jH2QUmkoIy--aQROFsx-3QPr8CjIfltTnhbZYGxsixI=@gpb.moe>
 <CAPyj-LBpmYv30JFW3x-ZL=28vivrh7d04L97rbXeYxDJirwKCg@mail.gmail.com>
 <ca1189e2-4bb7-3008-4b52-694cd14aed8d@php.net>
 <9c69992e-2962-476d-baca-aa51bdd0f1f7@bastelstu.be>
 <67f2f610-dca8-e8ce-a513-2aef0fcf2698@php.net>
Content-Language: en-US
In-Reply-To: <67f2f610-dca8-e8ce-a513-2aef0fcf2698@php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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