On 13/09/2017 12:01, Peter Maydell wrote: > On 13 September 2017 at 08:29, Sergey Smolov <smo...@ispras.ru> wrote: >> -d options are a bit high-level for me, because I just see the execution >> result for every instruction. So it will be a mistake to think that every >> change of some register's value is just a new value writing. >> >> As I understand, at "translate time" QEMU creates a TCG model that can be >> run as x86 code on the host machine. May be it is possible to find some >> mapping in this model between x86 and MIPS registers? Having such a mapping, >> one can detect that some value has been written in a x86 register that >> conforms to some GPR MIPS register. Am I right? > > No. The process of code generation does not care about > having consistent mapping between MIPS registers and > x86 registers -- all it does is ensure that architecturally > the right values are in the guest-visible registers when > they are visible to the guest. > > As I say, we may some day have a tracing API that allows you > to look at things at the level of detail that you want; > for now -d is the best we have. > > thanks > -- PMM >
(Especially while implementing new instructions), I tended to add couple of helper functions for tracing temporally. op_helper.c: void helper_trace_reg_access(CPUMIPSState *env, target_ulong val) { printf("reg = "TARGET_FMT_lx"\n", val); } helper.h: DEF_HELPER_2(trace_reg_access, void, env, tl) After this you could use the helper function where you want to trace the register value. For your case, you can add following line after the tcg_gen_mov_tl(). gen_helper_trace_reg_access(cpu_env, cpu_gpr[rs]); You will get the printf every time the part of code is being executed (which might be too often). Regards, Yongbok