Hi all,
I am the current maintainer of bytecode
(
https://github.com/MatthieuDartiailh/bytecode) which is a library
to perform assembly and disassembly of Python bytecode. The library
was created by V. Stinner.
I started looking in Python 3.11 support in bytecode, I read
Objects/exception_handling_notes.txt and I have a couple of
questions regarding the exception table:
Currently bytecode exposes three level of abstractions:
- the concrete level in which one deals with instruction offset
for jumps and explicit indexing into the known constants and names
- the bytecode level which uses labels for jumps and allow non
integer argument to instructions
- the cfg level which provides basic blocks delineation over the
bytecode level
So my first idea was to directly expose the unpacked exception table
(start, stop, target, stack_depth, last_i) at the concrete level and
use pseudo-instruction and labels at the bytecode level. At this
point of my reflections, I saw
https://github.com/python/cpython/commit/c57aad777afc6c0b382981ee9e4bc94c03bf5f68
about adding pseudo-instructionto dis output in 3.12 and though it
would line up quite nicely. Reading through, I got curious about how
SETUP_WITH handled
popping one extra item from the stack so I went to look at dis
results on a couple of small examples. I tried on 3.10 and
3.11b3 (for some reasons I cannot compile main at a391b74d on
windows).
I looked at simple things and got a bit surprised:
Disassembling:
def f():
try:
a = 1
except:
raise
I get on 3.11:
1 0 RESUME 0
2 2 NOP
3 4 LOAD_CONST 1 (1)
6 STORE_FAST 0 (a)
8 LOAD_CONST 0 (None)
10 RETURN_VALUE
>> 12 PUSH_EXC_INFO
4 14 POP_TOP
5 16 RAISE_VARARGS 0
>> 18 COPY 3
20 POP_EXCEPT
22 RERAISE 1
ExceptionTable:
4 to 6 -> 12 [0]
12 to 16 -> 18 [1] lasti
On 3.10:
2 0 SETUP_FINALLY 5 (to 12)
3 2 LOAD_CONST 1 (1)
4 STORE_FAST 0 (a)
6 POP_BLOCK
8 LOAD_CONST 0 (None)
10 RETURN_VALUE
4 >> 12 POP_TOP
14 POP_TOP
16 POP_TOP
5 18 RAISE_VARARGS 0
This surprised me on two levels:
- first I have never seen the RESUME opcode and it is currently
not documented
- my second surprise comes from the second entry in the
exception table. At first I failed to see why it was needed but
writing this I realize it corresponds to the explicit handling
of exception propagation to the caller. Since I cannot compile
3.12 ATM I am wondering how this plays with pseudo-instruction:
in particular are pseudo-instructions generated for all entries
in the exception table ?
My initial idea was to have a SETUP_FINALLY/SETUP_CLEANUP -
POP_BLOCK pair for each line in the exception table and label
for the jump target. But I realize it means we will have many
such pairs than in 3.10. It is fine by me but I wondered what
choice was made in 3.12 dis and if this approach made sense.
Best regards
Matthieu