On Thu, 8 Apr 2021 at 02:46, Robert Bu <[email protected]> wrote: > > Hi, > > I got some translation block execution trace with the runtime arguments: > -smp sockets=1 -smp cores=1 ---trace events=qemu-events -d > nochain,guest_errors -icount 0 > > qemu-events is shown as blow: > exec_tb > exec_tb_nocache > exec_tb_exit > sigjmp > translate_block > tb_invalidate > > where sigjmp, tb_invalidate are added by me. I got a trace snippet as: > > exec_tb tb=0x2b1e8414c780 pc=0x8004bfe4 > exec_tb_exit last_tb=0x0 flags=0x0 > exec_tb tb=0x2b1e8414c980 pc=0x8004bfd8 > exec_tb_exit last_tb=0x0 flags=0x0 > exec_tb tb=0x2b1e8414c780 pc=0x8004bfe4 > exec_tb_exit last_tb=0x0 flags=0x0 > exec_tb_exit last_tb=0x0 flags=0x0 > exec_tb tb=0x2b1e8414c780 pc=0x8004bfe4 > exec_tb_exit last_tb=0x0 flags=0x0 > exec_tb tb=0x2b1e8414c980 pc=0x8004bfd8 > exec_tb_exit last_tb=0x0 flags=0x0 > > It's weired that there are two consecutive exec_tb_exit without any exec_tb > in-between. I checked the source code without any luck to find any reasonable > reason. And also, the code block of pc=0x8004bfe4 is executed twice, which > not reasonable either.
That does seem a bit odd. If it's 100% reproducible, then try running QEMU under gdb and single step QEMU's execution of the TB to see what it's doing. (If it's not 100% reproducible, then 'rr' (https://rr-project.org/) may be useful in getting a recording of a failing execution which you can then step both backwards and forwards in.) (PS: also, you don't say what QEMU version you're using, so make sure this still happens on current-head-of-git.) -- PMM
