- matches at least one tuple in the
vjumptable or the
- is static
First, as noted above these two cases I think should better be different opcodes.
My desire in this EIP is not to introduce new opcodes, but to constrain the existing opcodes so that they are safer (as defined) without breaking too much existing code that is already safe.
Then, for the tabulated jump, I think validation should check:
jumpdest in both tables points to an instruction (is within > code bounds and doesn’t point to immediate)
- potentially we could restrict
jumpdest to point to
JUMPDEST opcode for consistency. Not sure it’s worth it, but it probably will simplify breaking into blocks?
jumpsrc could alse be additionally restricted to point to a tabulated jump instruction
- each tabulated jump instruction always has exactly one item in
vtraptable with corresponding
- number of items in
vjumptable for each
jumpsrc is not contstained (can be 0)
I think I just didn’t get around to validating the jump tables themselves, thanks for noticing. I think that will still require some version of jumpdest analysis be done.
JUMPDEST does makes it easier to break code into basic blocks with a simple one-pass algorithm. My intent is that every JUMP* instruction has at least one entry in the jumptable. And yes, there needs to be exactly one vtraptable destination for each JUMP*, and at most one vjumptable destination for every JUMP*.
Your algorithm code doesn’t seem to check all potential destinations of tabulated jumps, did you intend to support switch-like control flow with this at all?
Yes. Switches, virtual functions, and function pointers should all be handled via this mechanism.
Brooke and I are working on the algorithm, will be sure we get this right, thanks.