Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89851
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1512201853510.3190@whisky.home.derickrethans.nl>
References: <alpine.DEB.2.20.1512201853510.3190@whisky.home.derickrethans.nl>
Date: Sun, 20 Dec 2015 21:53:04 +0100
Message-ID: <CAF+90c-5OJTO_f1Te-O6kctsfWsA5Um7zkXVBOw2c-63q_M1PA@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Dmitry Stogov <dmitry@zend.com>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114264340e394805275a8f40
Subject: Re: CATCH in master (vs 7.0)
From: nikita.ppv@gmail.com (Nikita Popov)

--001a114264340e394805275a8f40
Content-Type: text/plain; charset=UTF-8

On Sun, Dec 20, 2015 at 9:06 PM, Derick Rethans <derick@php.net> wrote:

> Hi!
>
> I've been making sure Xdebug (and vld) compile with master as well - and
> while doing so I was retrofitting CATCH to use the extended value as a
> relative jump point (instead of absolute). Like:
>
> PHP 7.0:
> vld_printf (stderr, ", ->%d", op.extended_value);
>
> PHP 7.1:
> vld_printf (stderr, ", ->%d", nr + ((int) op.extended_value /
> sizeof(zend_op)));
>
> This works fine, and CATCH now shows:
>   18    46  E > > CATCH
> 'ExceptionFoo', !2, ->50
> again, instead of ->128
>
> However, the last CATCH, has a negative jump back to position 0 in PHP
> 7.1:
>
>   22    54  E > > CATCH
> 'ExceptionBaz', !2, ->0
>
> Instead of what it does for PHP 7.0, jump to after the CATCH state:
>
>   22    54  E > > CATCH
> 'ExceptionBaz', !2, ->57
>
>
> The whole section from VLD is:
>
>   17    43    >   EXT_STMT
>         44        ECHO
>  'Not+thrown%0A'
>         45      > JMP
> ->57
>   18    46  E > > CATCH
> 'ExceptionFoo', !2, ->50
>   19    47    >   EXT_STMT
>         48        ECHO
>  'caught%0A'
>         49      > JMP
> ->57
>   20    50  E > > CATCH
> 'ExceptionBar', !2, ->54
>   21    51    >   EXT_STMT
>         52        ECHO
>  'caught%0A'
>         53      > JMP
> ->57
>   22    54  E > > CATCH
> 'ExceptionBaz', !2, ->0   ***
>   23    55    >   EXT_STMT
>         56        ECHO
>  'caught%0A'
>   26    57    >   EXT_STMT
>         58        ECHO
>  'And+do+some+more%0A'
>   27    59        EXT_STMT
>         60      > RETURN
>  null
>
>
> *** is where the change happens from 57 to 0. However, I can't find *why*
> this
> happens, and whether it is actually correct? In the executor I can't see
> a separate check for "0" either - even if that is correct. What's the deal
> here?
>
> Then again, the logic sees the ->0 or ->57 both as an exit, as
> opcode.result.num == 1 for the 3rd catch. In zend_vm_execute, they do this,
> instead of the jump:
>
>             if (opline->result.num) {
>                 zend_throw_exception_internal(NULL);
>                 HANDLE_EXCEPTION();
>             }
>
> The file for which this happens is
> http://derickrethans.nl/files/dump/bug01034-003.txt
>
> cheers,
> Derick
>

The extended_value JMP_ADDR is only used if opline->result.num is 0.

opline->result.num here serves as a flag whether it is the last catch in
the sequence. If so, there is no further catch to jump to and instead the
exception is rethrown. extended_value will be some meaningless dummy value
in that case.

For VLD you should hide the value if opline->result.num is set, similar to
what zend_dump does:
http://lxr.php.net/xref/PHP_TRUNK/ext/opcache/Optimizer/zend_dump.c#644

Nikita

--001a114264340e394805275a8f40--