[Qemu-devel] gen_icount_start

[Qemu-devel] gen_icount_start

[biswaranjan panda]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

Hi ,

I am trying to understand how to count the number of instructions executed
in the guest and came across the gen_icount_start and gen_icount_end
functions.
What I understand is that in gen_icount_start 'icount_arg' keeps a pointer
to gen_opparam_ptr which is used in gen_icount_end to patch up the value .
I however didnt understand what the 'horrid hack' is about. Can any one
give me some idea on this ?

Thanks !

[-- Attachment #2: Type: text/html, Size: 609 bytes --]

Re: [Qemu-devel] gen_icount_start

[Peter Maydell]

On 30 December 2012 23:14, biswaranjan panda
<biswaranjan.nitrkl@gmail.com> wrote:
> What I understand is that in gen_icount_start 'icount_arg' keeps a pointer
> to gen_opparam_ptr which is used in gen_icount_end to patch up the value . I
> however didnt understand what the 'horrid hack' is about. Can any one give
> me some idea on this ?

My guess is that it's a hack because it's a layering violation. Functions
that generate TCG (intermediate representation) should do it by calling
the tcg_ functions, and the data structures and variables like
gen_opparam_ptr should be internal to the TCG layer. However here we
rely on knowing implementation details of how the TCG layer actually writes
out the ops and parameters when you call tcg_gen_subi_i32().
A clean design would make the TCG layer provide some kind of API for
writing out code and then fixing up the values afterwards, but on the other
hand if we only have one use case...

-- PMM

Re: [Qemu-devel] gen_icount_start

[biswaranjan panda]

[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]

> What I understand is that in gen_icount_start 'icount_arg' keeps a pointer
> to gen_opparam_ptr which is used in gen_icount_end to patch up the value
. I
> however didnt understand what the 'horrid hack' is about. Can any one give
> me some idea on this ?

>My guess is that it's a hack because it's a layering violation. Functions
>that generate TCG (intermediate representation) should do it by calling
>the tcg_ functions, and the data structures and variables like
>gen_opparam_ptr should be internal to the TCG layer. However here we
>rely on knowing implementation details of how the TCG layer actually writes
>out the ops and parameters when you call tcg_gen_subi_i32().
>A clean design would make the TCG layer provide some kind of API for
>writing out code and then fixing up the values afterwards, but on the other
>hand if we only have one use case...


Oh I just found out from the mailing list archives that '0xdeadbeef' is a
value that is later patched by the number of instructions 'num_insns' and
that is what the hack is about.

http://thread.gmane.org/gmane.comp.emulators.qemu/131848/focus=132842

Regards,
Biswa


On Sun, Dec 30, 2012 at 8:01 PM, Peter Maydell <peter.maydell@linaro.org>wrote:

> On 30 December 2012 23:14, biswaranjan panda
> <biswaranjan.nitrkl@gmail.com> wrote:
> > What I understand is that in gen_icount_start 'icount_arg' keeps a
> pointer
> > to gen_opparam_ptr which is used in gen_icount_end to patch up the value
> . I
> > however didnt understand what the 'horrid hack' is about. Can any one
> give
> > me some idea on this ?
>
> My guess is that it's a hack because it's a layering violation. Functions
> that generate TCG (intermediate representation) should do it by calling
> the tcg_ functions, and the data structures and variables like
> gen_opparam_ptr should be internal to the TCG layer. However here we
> rely on knowing implementation details of how the TCG layer actually writes
> out the ops and parameters when you call tcg_gen_subi_i32().
> A clean design would make the TCG layer provide some kind of API for
> writing out code and then fixing up the values afterwards, but on the other
> hand if we only have one use case...
>
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 4575 bytes --]