JUMPDEST instructions missing in CFG

Description

1. Not sure if it’s a bug or a feature, but the JUMPDEST at the start of jump targets isn’t shown in the CFG. See e.g. the JUMPI to offset 159, and the target node starts at offset 160.

1. Function names used to be shown in the CFG at the start of each function, those are gone as well.

How to Reproduce

Using Mythril 0.18.11 Pypi:

$ myth -g cfg.html -ia 0x35efabf6e2d970a3bc3fa1de991ec63987c127bc

Expected behavior

Include the JUMPDEST instruction at the start of the node or the function name if it’s the start of a function.

Environment

• Mythril version: 0.18.11 Pypi
• Python version: 3.6.3
• OS and Version: Mac OS High Sierra

[JoranHonig]

What about something like the following:

@instruction(auto_increment=False)
def jumpi_(self, global_state):
    ...
    new_state.mstate.pc = index
    ...

I think this will be simpler, and more easy to directly understand the meaning

[dmuhs]

@JoranHonig Thanks for clarifying. After having spent just a couple of hours with the LASER core routines it’s still quite a bit of black magic to me. As for the pc index of the JUMPDEST, instead of manipulating the @instruction decorator and having to deal with all instructions, we could simply decrement the index in the JUMP and JUMPI mutator functions. In these functions there’s already logic handling JUMPDEST instructions, so it wouldn’t add any bloat to the functions and we could simply set the index, e.g. in jumpi_ like such (in instructions.py:842):

        if instr['opcode'] == "JUMPDEST":
            if (type(condi) == bool and condi) or (type(condi) == BoolRef and not is_false(condi)):
                new_state = copy(global_state)
                new_state.mstate.pc = index - 1
                new_state.mstate.depth += 1
                new_state.mstate.constraints.append(condi)

                states.append(new_state)

While that still doesn’t look too clean as the -1 isn’t self-explanatory, I think it’s more elegant than handling the case in the instruction decorator. If we were to do the latter, we’d have to get the jump destination address there again and set the pc accordingly. But then we would’ve repeated the same logic again, which would make it harder to maintain and refactor. A comment at the pc change in the above code sample would of course also help make things clearer. 😄

Thoughts?