qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Instruction trace for ARM target


From: Klaus Goffart
Subject: Re: [Qemu-devel] Instruction trace for ARM target
Date: Fri, 04 Apr 2008 17:10:51 +0200

Hi,

first of all, thanks for your help.

Am Donnerstag, den 03.04.2008, 15:13 +0100 schrieb Stuart Brady: 
> On Wed, Apr 02, 2008 at 09:28:19PM +0200, Klaus Goffart wrote:
> > But, I'm not sure if these are all pc values. I do not completely
> > understand the way the helper_dump_pc() method is called, but it seems
> > that it is triggered in the disas_insn() respectively the
> > disas_arm_insn() method. But isn't each instruction just disassembled
> > once and then cached for the next execution? Then the corresponding pc
> > values would be missing.
> 
> That's why disas_insn() should call gen_op_dump_pc(), instead of calling
> helper_dump_pc() directly. 

OK. This was my first approach, so it missed pc values of reused code
blocks.

> Calling gen_op_dump_pc() adds the code
> needed to call helper_dump_pc() to the translation block that is
> currently being generated.

Just to make sure I picked it up right. The call of gen_op_dump_pc()
during translation adds the op_dump_pc() to the generated micro
instruction stream of the translation block. When the TB is executed,
the op_dump_pc() operation is called, calling helper_dump_pc() with
PARAM1. PARAM1 in op_dump_pc() is the first parameter passed to
gen_op_dump_pc(), i.e. s->pc. So the pc values to be traced are included
into the micro instruction stream and printed at execution time, right?

> The program counter isn't updated after each instruction is executed for
> performance reasons, so it's passed as a parameter during translation,
> whenever it is needed.  On the other hand, when the program counter is
> finally updated (e.g. after a conditional branch) you often can't
> determine its new value at translation time -- but where the instruction
> fetch occurs, this isn't a problem!
> 
> > To get the instructions being executed I call the ldl_code() method with
> > the actual pc value in the helper_dump_pc() method. It seems to work,
> > but it would be great if anybody could just point out if this is
> > correct.
> 
> If by 'actualy pc value', you mean the PC in the CPUState ('env'), then
> I'm very surprised that this would appear to produce correct output.

No, my helper_dump_pc() looks like this:

void helper_dump_pc(target_ulong pc) 
{
    if (logfile)
    {
        fputc('#', logfile);
        fwrite(&pc, sizeof(pc), 1, logfile);
        insn = ldl_code(pc);
        fwrite(&insn, sizeof(insn), 1, logfile);
    }   
}

> > My next step is to mark those instructions that are not executed due to
> > their condition codes and the memory accessed by executed instructions.
> > But I have no idea where this information is available. Can anybody give
> > me a clue?
> 
> Well, you'd certainly have to generate extra ops to mark instructions as
> executed, as instruction fetches occur at translation time. 

OK, so conditional instructions are skipped by a jump to the next
instruction if the condition code fails. This is what I found in the
documentation. In the code it looks like this jump is also a micro
operation. Therefore, an op should be placed right after the jump_op
that marks the last dumped instruction as executed. Is this what you
meant?

Thanks!

Klaus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]