py/bc: Fix size calculation of UNWIND_JUMP opcode in mp_opcode_format.

Prior to this patch mp_opcode_format would calculate the incorrect size of
the MP_BC_UNWIND_JUMP opcode, missing the additional byte.  But, because
opcodes below 0x10 are unused and treated as bytes in the .mpy load/save
and freezing code, this bug did not show any symptoms, since nested unwind
jumps would rarely (if ever) reach a depth of 16 (so the extra byte of this
opcode would be between 0x01 and 0x0f and be correctly loaded/saved/frozen
simply as an undefined opcode).

This patch fixes this bug by correctly accounting for the additional byte.
        .
This commit is contained in:
Damien George
2019-09-02 13:30:16 +10:00
parent c348e79187
commit b29fae0c56
4 changed files with 83 additions and 3 deletions

View File

@@ -292,7 +292,8 @@ continue2:;
#if MICROPY_PERSISTENT_CODE_LOAD || MICROPY_PERSISTENT_CODE_SAVE
// The following table encodes the number of bytes that a specific opcode
// takes up. There are 3 special opcodes that always have an extra byte:
// takes up. There are 4 special opcodes that always have an extra byte:
// MP_BC_UNWIND_JUMP
// MP_BC_MAKE_CLOSURE
// MP_BC_MAKE_CLOSURE_DEFARGS
// MP_BC_RAISE_VARARGS
@@ -402,7 +403,8 @@ uint mp_opcode_format(const byte *ip, size_t *opcode_size, bool count_var_uint)
ip += 3;
} else {
int extra_byte = (
*ip == MP_BC_RAISE_VARARGS
*ip == MP_BC_UNWIND_JUMP
|| *ip == MP_BC_RAISE_VARARGS
|| *ip == MP_BC_MAKE_CLOSURE
|| *ip == MP_BC_MAKE_CLOSURE_DEFARGS
);