Fix GH-18107: Opcache CFG jmp optimization with try-finally breaks the exception table

[nielsdos]

If there's a try-finally where the try_op starts on a basic block with a single JMP, and the JMP optimization causes that basic block to become unreachable, then we update try_op.
In this case, there is no catch_op, so try_op is erroneously set to 0, we should instead set it to b->start.

This is a significantly reduced test case from the original code, so the code looks a bit unrealistic but is simple.

[dstogov]

I'm not 100% sure.

You fix problem for for case without catch blocks. This looks right.

Please also check the case when we have catch block, but all try blocks are unreachable. Previously, we set try_op to the first catch block, but with your fix we may probably set it not to the first catch block.

[nielsdos]

If the try block is unreachable, we first use the catch blocks if one of them is reachable:

php-src/Zend/Optimizer/zend_cfg.c

Lines 131 to 140 in 8c7e856

	if (op_array->try_catch_array[j].catch_op) {
	end = blocks + block_map[op_array->try_catch_array[j].catch_op];
	while (b != end) {
	if (b->flags & ZEND_BB_REACHABLE) {
	op_array->try_catch_array[j].try_op = b->start;
	break;
	}
	b++;
	}
	}

This executes before using the finally blocks, i.e. before the code I changed.

---

I also tried some testing with PHP code.

1. If I add a catch to the phpt test then nothing changes because the catch block is dead as well.

2. In this case:

<?php

if (!isset($badvar)) {
    throw new Exception("Should happen");
}
try {
    goto foo;
} catch (Throwable $e) {
    foo:;
} finally {
    throw new Exception("Should not happen");
}

0000 T2 = ISSET_ISEMPTY_CV (isset) CV0($badvar)
0001 JMPNZ T2 0007
0002 V4 = NEW 1 string("Exception")
0003 SEND_VAL_EX string("Should happen") 1
0004 DO_FCALL
0005 THROW V4
0006 CV1($e) = CATCH string("Throwable")
0007 T6 = FAST_CALL 0009
0008 JMP 0014
0009 V7 = NEW 1 string("Exception")
0010 SEND_VAL_EX string("Should not happen") 1
0011 DO_FCALL
0012 THROW V7
0013 FAST_RET T6
0014 RETURN int(1)
EXCEPTION TABLE:
     0007, 0006, 0009, 0013

Prior to this PR, the try_op and catch_op pointed to the 0006 CV1($e) = CATCH string("Throwable") opline, whereas now we have the try_op pointing to the 0007 T6 = FAST_CALL 0009. However, I think this should be fine given that the CATCH op can't actually execute.

[dstogov]

EXCEPTION TABLE:
     0007, 0006, 0009, 0013

Prior to this PR, the try_op and catch_op pointed to the 0006 CV1($e) = CATCH string("Throwable") opline, whereas now we have the try_op pointing to the 0007 T6 = FAST_CALL 0009. However, I think this should be fine given that the CATCH op can't actually execute.

Thanks for analyses.
This is what I was afraid of.
See the "exception table try_op - 0007 is above the catch_op - 0006.
This may confuse C code that iterated from try_op to catch_op. Actually the C loop posted above is affected.

The fix should be simple.