On 07/07/2017 07:36 AM, Peter Maydell wrote:
On 7 July 2017 at 18:32, Alex Bennée <alex.ben...@linaro.org> wrote:
Given the wording of:
/* is_jmp field values */
#define DISAS_NEXT 0 /* next instruction can be analyzed */
#define DISAS_JUMP 1 /* only pc was modified dynamically */
#define DISAS_UPDATE 2 /* cpu state was modified dynamically */
#define DISAS_TB_JUMP 3 /* only pc was modified statically */
I'm thinking that really these DISAS_JUMP's should be DISAS_UPDATEs and
we need to disable the TB chaining optimisations for this. I'll prepare
a more comprehensive series next week. However testing this patch for
known failure modes will be useful.
The problem I think is that a lot of our current code assumes
that DISAS_UPDATE means "go back to the top loop".
In any case I think you are right that DISAS_UPDATE should not
allow chaining to the next TB, because it implies that perhaps
a TB flags bit got changed, so you need to look in the hash
table again.
Changes to TB flags are not a problem; helper_lookup_tb does examine them, and
indeed go back to the hash table. The only thing it doesn't do is re-evaluate
the interrupt state.
Naming all of these different exit conditions is certainly non-trivial.
r~
