From: Stuart Brady <sdbrady@ntlworld.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Instruction trace for ARM target
Date: Thu, 3 Apr 2008 15:13:13 +0100 [thread overview]
Message-ID: <20080403141313.GA15754@miranda.arrow> (raw)
In-Reply-To: <1207164499.9736.32.camel@goffart-laptop>
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. Calling gen_op_dump_pc() adds the code
needed to call helper_dump_pc() to the translation block that is
currently being generated.
Actually, with the code in SVN, you'd probably want something like:
tcg_gen_helper_0_1(helper_dump_pc, tcg_const_ptr(s->pc));
You would then no longer need op_dump_pc().
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.
> 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. For memory
access, you could modify the memory accessors to perform the marking...
probably by adding helper calls in tcg-op.h.
Cheers,
--
Stuart Brady
next prev parent reply other threads:[~2008-04-03 14:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-02 19:28 [Qemu-devel] Instruction trace for ARM target Klaus Goffart
2008-04-03 14:13 ` Stuart Brady [this message]
2008-04-04 15:10 ` Klaus Goffart
2008-04-07 21:58 ` Stuart Brady
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080403141313.GA15754@miranda.arrow \
--to=sdbrady@ntlworld.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).