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
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
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 ->128However, the last CATCH, has a negative jump back to position 0 in PHP
7.1:22 54 E > > CATCH
'ExceptionBaz', !2, ->0Instead of what it does for PHP 7.0, jump to after the CATCH state:
22 54 E > > CATCH
'ExceptionBaz', !2, ->57The 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.txtcheers,
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
Am 20.12.2015 um 21:53 schrieb Nikita Popov:
For VLD you should hide the value if opline->result.num is set, similar to
what zend_dump does:
Is zend_dump() callable from userland?
On Mon, Dec 21, 2015 at 8:24 AM, Sebastian Bergmann sebastian@php.net
wrote:
Am 20.12.2015 um 21:53 schrieb Nikita Popov:
For VLD you should hide the value if opline->result.num is set, similar
to
what zend_dump does:Is zend_dump() callable from userland?
It's a part of ext/opcache and used to debug Optimizer. -d
opcache.opt_debug_level=0xffffffff will dump after each optimization pass.
Am 21.12.2015 um 06:24 schrieb Sebastian Bergmann sebastian@php.net:
Am 20.12.2015 um 21:53 schrieb Nikita Popov:
For VLD you should hide the value if opline->result.num is set, similar to
what zend_dump does:Is zend_dump() callable from userland?
No, and it's a function only available when Optimizer is loaded (which makes sense as it also dumps some optimizer specific structures).
Bob
Am 21.12.2015 um 06:24 schrieb Sebastian Bergmann sebastian@php.net:
Am 20.12.2015 um 21:53 schrieb Nikita Popov:
For VLD you should hide the value if opline->result.num is set, similar
to
what zend_dump does:Is zend_dump() callable from userland?
No, and it's a function only available when Optimizer is loaded (which
makes sense as it also dumps some optimizer specific structures).
We have a though about moving Optimizer into Zend, but we didn't make final
decision yet.
Bob