Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89934
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Thu, 31 Dec 2015 00:09:21 +0000 (GMT)
To: Nikita Popov <nikita.ppv@gmail.com>
cc: PHP Developers Mailing List <internals@lists.php.net>, 
    Dmitry Stogov <dmitry@zend.com>
In-Reply-To: <CAF+90c-T99JfCt5yXaJ3mCXiViaohV0tOF+dqFSHPH=jKZ_6mw@mail.gmail.com>
Message-ID: <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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1360942977-1451520562=:3125"
Subject: Re: Line numbers for "finally"
From: derick@php.net (Derick Rethans)

--8323329-1360942977-1451520562=:3125
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi!

On Thu, 31 Dec 2015, Nikita Popov wrote:

> On Wed, Dec 30, 2015 at 8:55 PM, Derick Rethans <derick@php.net> wrote:
>=20
> > While investigating an issue with Xdebug and fast_call/fast_ret, I
> > noticed that the opcodes "associated" with the "finally" statement, are
> > rolled up in the previous line.

<snip>

> > The FAST_CALL/JMP instructions should really be linked to line 10.=20
> > Not doing so produces confusing results while doing code coverage,=20
> > where it now shows that the "echo catch2\n" on line 9 is executed.=20
> > This is of course not the case, but the linking of FAST_CALL and JMP=20
> > to line 9 makes it look like this. Is it possible to change this so=20
> > thta the FAST_CALL and JMP are linked to line 10 instead?
> >
>=20
> Yeah, you're right. Should be fixed with=20
> https://github.com/php/php-src/commit/b3afeeabefc4777ec4797a7e2c3688e9e20=
be4cc=20
> .

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=20
> > jump to. Right now, I have:
> >
> > https://github.com/derickr/vld/commit/9cf01bba0a1aeef6a261c6c85b2385522=
15a9f0b#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_num=
);
> > +               }
> > +               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_num=
);
> > +               }
> > +               return 1;
> > +#endif
> >
> > Which seems to work, although I am unsure about the "+ 1" for FAST_RET.
> >
>=20
> 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 encode=
d
> in the opline. It will either jump back to one past the invoking FAST_CAL=
L
> (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?=20
(PR welcome :D )

cheers,
Derick
--8323329-1360942977-1451520562=:3125--