Kyle Zeng

the result of `state.step()` from 0x3db14 is: ~~~ [, , , , , ] ~~~

VEX does not break the block at 0x43DB1C. VEX and QEMU agree on this: the block is from 0x0003DB14 to 0x003DB3C

QEMU only shows [0x0003DB14, 0x003DB3C] in the trace, but angr shows much more than that, something like [0x0003DB14, 0x0003DB1C, ...., 0x003DB3C]. so tracer freaks out.

OK. So it sounds like the root cause if the definition of "basic block" is different in VEX because it does not have the semantic information that conditional execution is...

This means the assumption we have in tracer that angr executes on "basic block"(in the sense of ARM instructions) is wrong

I'm not an expert in pyvex engine. But is it possible to make pyvex specifically not mark conditional execution as the end of a basic block? So that the definitions...

@ltfish I'm sure because continuing executing the same state eventually reaches the address that in QEMU's trace. And the execution trace is basically the basic block

@rhelmot Instead of changing how it is lifted which is hard for all instructions, can we change how it generates successors? Like: if it stops at a "jump" that is...

see some more discussion [HERE](https://github.com/angr/angr-doc/pull/190)

It's good to know you are working on this. Actually, after a symbolic address has been concretised, there is no way to predict how many bytes will be written into...