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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
