Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89944
Return-Path: <nikita.ppv@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 13963 invoked from network); 31 Dec 2015 16:48:54 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 31 Dec 2015 16:48:54 -0000
Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.171 as permitted sender)
X-PHP-List-Original-Sender: nikita.ppv@gmail.com
X-Host-Fingerprint: 209.85.160.171 mail-yk0-f171.google.com  
Received: from [209.85.160.171] ([209.85.160.171:36516] helo=mail-yk0-f171.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 1D/8E-51216-57C55865 for <internals@lists.php.net>; Thu, 31 Dec 2015 11:48:53 -0500
Received: by mail-yk0-f171.google.com with SMTP id v14so90293466ykd.3
        for <internals@lists.php.net>; Thu, 31 Dec 2015 08:48:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        bh=CskYfVPckHM1MMA4yqVVQKLT6NbCT1wpDxXflEs+490=;
        b=AS5Ajcn6pxIZ31GPrexMt9zu8RmEfWYb63HKTqrlQUrhqqIfm0p4SZijTTZG0ge9Ku
         cjcBjkOhROE8fUdT1aKqwN76rqCmL8OnoQkyh8cH+t67Cnfa9z3xihZc/XBxfR98XIy7
         nMasTg+q/wWWLMqOFFK3PUxa5KICBHlIVX1doLj2xiQapCeR8WAHL2RvV5ACcKN8z06Q
         S/Md1MibpO3jYElJzhGFHRmigtwJR72W+v2X3+cT38tSeDPAyp4X8HRart9a1/j2G9ZT
         b2/MovSWCzVw7wLUAS3aIWMDvIq2HSvKMH4PJXLlJ4SZ/qTt4ColSUN/X8+VUGkDm6BP
         V8ZQ==
MIME-Version: 1.0
X-Received: by 10.129.50.199 with SMTP id y190mr58183389ywy.147.1451580531315;
 Thu, 31 Dec 2015 08:48:51 -0800 (PST)
Received: by 10.129.148.70 with HTTP; Thu, 31 Dec 2015 08:48:51 -0800 (PST)
In-Reply-To: <alpine.DEB.2.20.1512310005200.3125@whisky.home.derickrethans.nl>
References: <alpine.DEB.2.20.1512301923000.3125@whisky.home.derickrethans.nl>
	<CAF+90c-T99JfCt5yXaJ3mCXiViaohV0tOF+dqFSHPH=jKZ_6mw@mail.gmail.com>
	<alpine.DEB.2.20.1512310005200.3125@whisky.home.derickrethans.nl>
Date: Thu, 31 Dec 2015 17:48:51 +0100
Message-ID: <CAF+90c_9aX+0B9tyxpgCYOj6kDq0=GSPUG9f_uf0eMCNNg2R_g@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP Developers Mailing List <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>
Content-Type: multipart/alternative; boundary=001a1140847eee9bb70528346d75
Subject: Re: Line numbers for "finally"
From: nikita.ppv@gmail.com (Nikita Popov)

--001a1140847eee9bb70528346d75
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 31, 2015 at 1:09 AM, Derick Rethans <derick@php.net> wrote:

> Hi!
>
> On Thu, 31 Dec 2015, Nikita Popov wrote:
>
> > On Wed, Dec 30, 2015 at 8:55 PM, Derick Rethans <derick@php.net> wrote:
> >
> > > While investigating an issue with Xdebug and fast_call/fast_ret, I
> > > noticed that the opcodes "associated" with the "finally" statement, a=
re
> > > rolled up in the previous line.
>
> <snip>
>
> > > The FAST_CALL/JMP instructions should really be linked to line 10.
> > > Not doing so produces confusing results while doing code coverage,
> > > where it now shows that the "echo catch2\n" on line 9 is executed.
> > > This is of course not the case, but the linking of FAST_CALL and JMP
> > > to line 9 makes it look like this. Is it possible to change this so
> > > thta the FAST_CALL and JMP are linked to line 10 instead?
> > >
> >
> > Yeah, you're right. Should be fixed with
> >
> https://github.com/php/php-src/commit/b3afeeabefc4777ec4797a7e2c3688e9e20=
be4cc
> > .
>
> Thanks =E2=80=94 I'll give that a shot tomorrow. Did you merge that to 7.=
0 too?
>
> > > And secondly, I am struggeling with where FAST_CALL and FAST_RET can
> > > jump to. Right now, I have:
> > >
> > >
> https://github.com/derickr/vld/commit/9cf01bba0a1aeef6a261c6c85b238552215=
a9f0b#diff-286f7620179e1ee0a20e81523d91ff24R1036
> > >
> > > +#if PHP_VERSION_ID >=3D 50500
> > > +       } else if (opcode.opcode =3D=3D ZEND_FAST_CALL) {
> > > +#if PHP_VERSION_ID >=3D 70000
> > > +               *jmp1 =3D VLD_ZNODE_JMP_LINE(opcode.op1, position,
> base_address);
> > > +#else
> > > +               *jmp1 =3D ((long) VLD_ZNODE_ELEM(opcode.op1, jmp_addr=
) -
> (long) base_address) / sizeof(zend_op);
> > > +#endif
> > > +               if (opcode.extended_value) {
> > > +                       *jmp2 =3D VLD_ZNODE_ELEM(opcode.op2, opline_n=
um);
> > > +               }
> > > +               return 1;
> > > +       } else if (opcode.opcode =3D=3D ZEND_FAST_RET) {
> > > +               *jmp1 =3D position + 1;
> > > +               if (opcode.extended_value) {
> > > +                       *jmp2 =3D VLD_ZNODE_ELEM(opcode.op2, opline_n=
um);
> > > +               }
> > > +               return 1;
> > > +#endif
> > >
> > > Which seems to work, although I am unsure about the "+ 1" for FAST_RE=
T.
> > >
> >
> > For PHP 7 only: FAST_CALL always jumps to op1. op2 is not a jmp addr,
> it's
> > a try_catch_array offset. For FAST_RET there are no jump addresses
> encoded
> > in the opline. It will either jump back to one past the invoking
> FAST_CALL
> > (of which there may be multiple), or (if finally is executed due to an
> > uncaught exception) it will jump back to the next applicable catch or
> > finally or leave the function.
>
> Hmm, that's more complicated than I thought. How would I fix that code?
> (PR welcome :D )
>

I don't know what you need this for, but maybe you can use the same "good
enough" approximation we use for our internal control flow analysis, namely
simply say that FAST_CALL either jumps to op1 or to the next instruction,
while FAST_RET is treated as a terminator instruction (like RETURN). This
does not accurately model control flow, but it may be sufficient for your
purposes.

Nikita

--001a1140847eee9bb70528346d75--