On 13/09/2017 12:01, Peter Maydell wrote:
> On 13 September 2017 at 08:29, Sergey Smolov <[email protected]> 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
