On 7/30/23 13:37, Helge Deller wrote:
On 7/30/23 22:03, Richard Henderson wrote:
On 7/30/23 10:56, Helge Deller wrote:
I'm quite unclear about translator_use_goto_tb() for qemu-user
emulation....(and in general).
Based on the function name, the function translator_use_goto_tb() shall
help to decide if a program should use goto_tb() and exit_tb() to jump
to the next instruction.
Currently, if the destination is on the same page, it returns true.
I wonder, if it shouldn't return false in this case instead, because
arches have code like this: (taken from target/hppa/translate.c):
if (... && translator_use_goto_tb(ctx, f)) {
tcg_gen_goto_tb(which);
tcg_gen_movi_reg(cpu_iaoq_f, f);
tcg_gen_movi_reg(cpu_iaoq_b, b);
tcg_gen_exit_tb(ctx->base.tb, which);
} else {
copy_iaoq_entry(cpu_iaoq_f, f, cpu_iaoq_b);
copy_iaoq_entry(cpu_iaoq_b, b, ctx->iaoq_n_var);
tcg_gen_lookup_and_goto_ptr();
}
Shouldn't, if the destination is on the same page, the (faster?)
path with tcg_gen_lookup_and_goto_ptr() be taken instead?
No, because tcg_gen_lookup_and_goto_ptr is not the faster path.
That always involves a lookup, then an indirect branch.
Ah, ok. So my assumption was wrong, and this explains it.
The goto_tb path is linked, so only requires a lookup once, and the
branch may be direct (depending on the host architecture).
Probably the last question in this regard:
This code:
IN:
0x00010c98: cmpib,<>,n 0,r19,0x10c98
generates "nop/jmp" in the code:
the tcg_gen_goto_tb() branch:
OUT:
0x7fd7e400070e: 85 db testl %ebx, %ebx
0x7fd7e4000710: 0f 85 20 00 00 00 jne 0x7fd7e4000736
0x7fd7e4000716: 90 nop <- from
"tcg_gen_op1i(INDEX_op_goto_tb, idx)" in tcg_gen_goto_tb()
0x7fd7e4000717: e9 00 00 00 00 jmp 0x7fd7e400071c <- jump is effective
useless.
0x7fd7e400071c: c7 45 00 a3 0c 01 00 movl $0x10ca3, (%rbp)
0x7fd7e4000723: c7 45 04 a7 0c 01 00 movl $0x10ca7, 4(%rbp)
0x7fd7e400072a: 48 8d 05 0f ff ff ff leaq -0xf1(%rip), %rax
0x7fd7e4000731: e9 e2 f8 ff ff jmp 0x7fd7e4000018
0x7fd7e4000736: 90 nop <- here too.
0x7fd7e4000737: e9 00 00 00 00 jmp 0x7fd7e400073c
0x7fd7e400073c: c7 45 00 9f 0c 01 00 movl $0x10c9f, (%rbp)
0x7fd7e4000743: c7 45 04 9b 0c 01 00 movl $0x10c9b, 4(%rbp)
0x7fd7e400074a: 48 8d 05 f0 fe ff ff leaq -0x110(%rip), %rax
0x7fd7e4000751: e9 c2 f8 ff ff jmp 0x7fd7e4000018
I assume those nops/jmp+0 is to be able to insert breakpoints?
No.
The destination of the jmp is patched by tb_target_set_jmp_target, which happens some time
after this disassembly. The nop is present to ensure that the patch point is aligned, so
that it is one 4-byte atomic store.
r~
