Re: Line numbers for "finally"

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, > > are > > 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 > ‹Ã¹½yo–ò > 4HabžRrhttps://github.com/php/php-src/commit/b3afeeabefc4777ec4797a7e2c3688e9e20be4cc > > . Thanks — 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/9cf01bba0a1aeef6a261c6c85b238552215a9f0b#diff-286f7620179e1ee0a20e81523d91ff24R1036 > > > > +#if PHP_VERSION_ID >= 50500 > > + } else if (opcode.opcode == ZEND_FAST_CALL) { > > +#if PHP_VERSION_ID >= 70000 > > + *jmp1 = VLD_ZNODE_JMP_LINE(opcode.op1, position, base_address); > > +#else > > + *jmp1 = ((long) VLD_ZNODE_ELEM(opcode.op1, jmp_addr) - (long) > > base_address) / sizeof(zend_op); > > +#endif > > + if (opcode.extended_value) { > > + *jmp2 = VLD_ZNODE_ELEM(opcode.op2, opline_num); > > + } > > + return 1; > > + } else if (opcode.opcode == ZEND_FAST_RET) { > > + *jmp1 = position + 1; > > + if (opcode.extended_value) { > > + *jmp2 = VLD_ZNODE_ELEM(opcode.op2, opline_num); > > + } > > + return 1; > > +#endif > > > > Which seems to work, although I am unsure about the "+ 1" for FAST_RET. > > > > 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 ) cheers, Derick