[Qemu-devel] MIPS 'move' insn emulation

[Qemu-devel] MIPS 'move' insn emulation

[Sergey Smolov]

Hello, List!

I run MIPS assembler program on QEMU. The program is just a sample, here 
is the code:

.text
     addiu $8, $zero, 0x7
     move $9, $8
     sll $8, $8, 3
     add $8, $8, $9

The program finishes on QEMU with the following values for registers, 
and it's ok:

$8 - 0x3f
$9 - 0x7

Now I want to implement some logging features for MIPS assembler 
programs. For example, I want to write a record to log every time the 
'move' instruction writes some value to GPR register.

I've the code I probably need to modify in target/mips/translate.c:

[code]

static void gen_logic(DisasContext *ctx, uint32_t opc,
                       int rd, int rs, int rt)
{
...
} else if (rs != 0 && rt == 0) {
             tcg_gen_mov_tl(cpu_gpr[rd], cpu_gpr[rs]);
}

[/code]

I suppose that for my assembler program cpu_gpr[rs] here should contain 
0x7 value at runtime. Is it possible to extract this value somehow? I've 
tried the following constructions:

GET_TCG_I32(cpu_gpr[rs])
((CPUMIPSState *)tcg_ctx.cpu)->active_tc.gpr[rs]

but they do not provide me the correct value. Could you help me in 
solving this problem?

Thanks in advance,
  Sergey Smolov

Re: [Qemu-devel] MIPS 'move' insn emulation

[Peter Maydell]

On 12 September 2017 at 15:14, Sergey Smolov <smolov@ispras.ru> wrote:
> I've the code I probably need to modify in target/mips/translate.c:
>
> [code]
>
> static void gen_logic(DisasContext *ctx, uint32_t opc,
>                       int rd, int rs, int rt)
> {
> ...
> } else if (rs != 0 && rt == 0) {
>             tcg_gen_mov_tl(cpu_gpr[rd], cpu_gpr[rs]);
> }
>
> [/code]
>
> I suppose that for my assembler program cpu_gpr[rs] here should contain 0x7
> value at runtime. Is it possible to extract this value somehow? I've tried
> the following constructions:
>
> GET_TCG_I32(cpu_gpr[rs])
> ((CPUMIPSState *)tcg_ctx.cpu)->active_tc.gpr[rs]
>
> but they do not provide me the correct value.

You can't do this in this bit of the code. The functions in
translate.c are called at "translate time", when we convert
MIPS assembly into x86 code to run on the host. At this point
we don't know what the values in MIPS registers are, because
we're generating code that will later be run multiple times
perhaps with different values. The register contents are only
known later, at "run time".

thanks
-- PMM

Re: [Qemu-devel] MIPS 'move' insn emulation

[Sergey Smolov]

On 12.09.2017 17:32, Peter Maydell wrote:
> On 12 September 2017 at 15:14, Sergey Smolov <smolov@ispras.ru> wrote:
>> I've the code I probably need to modify in target/mips/translate.c:
>>
>> [code]
>>
>> static void gen_logic(DisasContext *ctx, uint32_t opc,
>>                        int rd, int rs, int rt)
>> {
>> ...
>> } else if (rs != 0 && rt == 0) {
>>              tcg_gen_mov_tl(cpu_gpr[rd], cpu_gpr[rs]);
>> }
>>
>> [/code]
>>
>> I suppose that for my assembler program cpu_gpr[rs] here should contain 0x7
>> value at runtime. Is it possible to extract this value somehow? I've tried
>> the following constructions:
>>
>> GET_TCG_I32(cpu_gpr[rs])
>> ((CPUMIPSState *)tcg_ctx.cpu)->active_tc.gpr[rs]
>>
>> but they do not provide me the correct value.
> You can't do this in this bit of the code. The functions in
> translate.c are called at "translate time", when we convert
> MIPS assembly into x86 code to run on the host. At this point
> we don't know what the values in MIPS registers are, because
> we're generating code that will later be run multiple times
> perhaps with different values. The register contents are only
> known later, at "run time".
>
> thanks
> -- PMM

Thank you, Peter.

Generally speaking, is it possible at "run time" to detect write 
accesses to MIPS GPR registers?
If true, which parts of code should I look in?

-- 
Sincerely yours,
Sergey Smolov

Re: [Qemu-devel] MIPS 'move' insn emulation

[Peter Maydell]

On 12 September 2017 at 15:53, Sergey Smolov <smolov@ispras.ru> wrote:
> Generally speaking, is it possible at "run time" to detect write accesses to
> MIPS GPR registers?
> If true, which parts of code should I look in?

We don't currently support tracing at that level, I'm afraid.
(There are some patches on list starting to explore providing
an API for doing this kind of instrumentation, but they're
still at the "working out a design" stage.)
You might want to look at the -d options, which can give
you register dumps before every executed instruction if
you pick the right set of options (-d exec,cpu,nochain
-singlestep is probably a start.)

thanks
-- PMM

Re: [Qemu-devel] MIPS 'move' insn emulation

[Sergey Smolov]

On 12.09.2017 18:06, Peter Maydell wrote:
> On 12 September 2017 at 15:53, Sergey Smolov <smolov@ispras.ru> wrote:
>> Generally speaking, is it possible at "run time" to detect write accesses to
>> MIPS GPR registers?
>> If true, which parts of code should I look in?
> We don't currently support tracing at that level, I'm afraid.
> (There are some patches on list starting to explore providing
> an API for doing this kind of instrumentation, but they're
> still at the "working out a design" stage.)
> You might want to look at the -d options, which can give
> you register dumps before every executed instruction if
> you pick the right set of options (-d exec,cpu,nochain
> -singlestep is probably a start.)
>
> thanks
> -- PMM

-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?

-- 
Sincerely yours,
Sergey Smolov

Re: [Qemu-devel] MIPS 'move' insn emulation

[Peter Maydell]

On 13 September 2017 at 08:29, Sergey Smolov <smolov@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

Re: [Qemu-devel] MIPS 'move' insn emulation

[Yongbok Kim]

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

Re: [Qemu-devel] MIPS 'move' insn emulation

[Sergey Smolov]

On 13.09.2017 17:20, Yongbok Kim wrote:
> (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

Thanks, Yongbok!

I've implemented the code you've written. Now I receive values are 
written into MIPS registers.

Could you explain some aspects about the code you propose?

First, what is the helper function itself? Peter said that it is 
impossible to get the value that is written to MIPS register at 
"translation time", but in "run time" there is no mapping between x86 
and "virtual MIPS" registers. So how it is possible to get these values?:-)

Second, I need to make a final modification of helper function. I need 
to print both "val" that is written to GPR register and the number "num" 
of the register. I wrote the following:

op_helper.c:
void helper_trace_reg_access(CPUMIPSState *env, int reg, target_ulong val)
{
qemu_log("r%d = "TARGET_FMT_lx"\n", reg, val);
}

helper.h:
DEF_HELPER_3(trace_reg_access, void, env, int, tl)

and call the function in translate.c like:

gen_helper_trace_reg_access(cpu_env, rd, cpu_gpr[rs]);

But when I compile the QEMU, i get this:
In function ‘gen_logic’:
target/mips/translate.c:2913:13: warning: passing argument 2 of 
‘gen_helper_trace_reg_access’ makes pointer from integer without a cast 
[enabled by default]

What am I missing here?

-- 
Sincerely yours,
Sergey Smolov

Re: [Qemu-devel] MIPS 'move' insn emulation

[Peter Maydell]

On 14 September 2017 at 14:49, Sergey Smolov <smolov@ispras.ru> wrote:
> I've implemented the code you've written. Now I receive values are written
> into MIPS registers.
>
> Could you explain some aspects about the code you propose?
>
> First, what is the helper function itself? Peter said that it is impossible
> to get the value that is written to MIPS register at "translation time", but
> in "run time" there is no mapping between x86 and "virtual MIPS" registers.
> So how it is possible to get these values?:-)

At translate time it is generating some extra code which at runtime
will call the helper_trace_reg_access() function, passing it the
values in the registers at this point. This will result in poor
performance if you do it for frequently executed instructions.

> Second, I need to make a final modification of helper function. I need to
> print both "val" that is written to GPR register and the number "num" of the
> register. I wrote the following:
>
> op_helper.c:
> void helper_trace_reg_access(CPUMIPSState *env, int reg, target_ulong val)
> {
> qemu_log("r%d = "TARGET_FMT_lx"\n", reg, val);
> }
>
> helper.h:
> DEF_HELPER_3(trace_reg_access, void, env, int, tl)
>
> and call the function in translate.c like:
>
> gen_helper_trace_reg_access(cpu_env, rd, cpu_gpr[rs]);
>
> But when I compile the QEMU, i get this:
> In function ‘gen_logic’:
> target/mips/translate.c:2913:13: warning: passing argument 2 of
> ‘gen_helper_trace_reg_access’ makes pointer from integer without a cast
> [enabled by default]
>
> What am I missing here?

That looks like it ought to work. Check you really did save all your
files in your editor before compiling? :-)

PS: there's no point passing the env pointer into the function if
you're not going to use it...

thanks
-- PMM

Re: [Qemu-devel] MIPS 'move' insn emulation

[Sergey Smolov]

On 14.09.2017 16:58, Peter Maydell wrote:
> At translate time it is generating some extra code which at runtime
> will call the helper_trace_reg_access() function, passing it the
> values in the registers at this point. This will result in poor
> performance if you do it for frequently executed instructions.

Ok, thank you.

> That looks like it ought to work. Check you really did save all your
> files in your editor before compiling? :-)

Yes, I did. These warnings are very suspicious, because they come with 
strange numbers of MIPS GPR registers that I receive for my program.

Here is the program:

.text
     addiu $8, $zero, 0x7
     move $9, $8
     sll $8, $8, 3
     add $8, $8, $9

Here is the log that helper functions provide:

$0 00000007
$7 00000007
$0 00000038
$0 0000003f

The first value is register name, the second is the value to be written. 
Values are ok, but I expect to see $8 and $9  registers here.

>
> PS: there's no point passing the env pointer into the function if
> you're not going to use it...

I thought that I need to pass env pointer to helper function because of 
some convention. Again, thank you for the note.

-- 
Sincerely yours,
Sergey Smolov

Re: [Qemu-devel] MIPS 'move' insn emulation

[Yongbok Kim]

On 14/09/2017 15:16, Sergey Smolov wrote:
> 
> On 14.09.2017 16:58, Peter Maydell wrote:
>> At translate time it is generating some extra code which at runtime
>> will call the helper_trace_reg_access() function, passing it the
>> values in the registers at this point. This will result in poor
>> performance if you do it for frequently executed instructions.

Yes indeed. it will be hitting the performance critically the instruction
is quite often used. :)

> 
> Ok, thank you.
> 
>> That looks like it ought to work. Check you really did save all your
>> files in your editor before compiling? :-)
> 
> Yes, I did. These warnings are very suspicious, because they come with
> strange numbers of MIPS GPR registers that I receive for my program.
> 
> Here is the program:
> 
> .text
>     addiu $8, $zero, 0x7
>     move $9, $8
>     sll $8, $8, 3
>     add $8, $8, $9
> 
> Here is the log that helper functions provide:
> 
> $0 00000007
> $7 00000007
> $0 00000038
> $0 0000003f
> 
> The first value is register name, the second is the value to be written.
> Values are ok, but I expect to see $8 and $9  registers here.
> 
>>
>> PS: there's no point passing the env pointer into the function if
>> you're not going to use it...

Yes you're right. I had further use of the env but it has been chopped for
the example.

> 
> I thought that I need to pass env pointer to helper function because of
> some convention. Again, thank you for the note.
> 

Sergey,

The reason why your modification is failed is because you passed wrong
argument. Remember that you are not just calling the helper function from
translate.c but you are generating some code to let call the helper
function on run time. You have to create a temporal TCGv to pass the
register number.
You could do it like,
TCGv_i32 tmp = tcg_const_i32(rd)
gen_helper_trace_reg_access(cpu_env, tmp, cpu_gpr[rs);
tcg_temp_free_i32(tmp);

or simply use the predefined macro and fix the order of the arguments.

gen_helper_0e1i(trace_reg_access, cpu_gpr[rs], rd);

Regards,
Yongbok

Re: [Qemu-devel] MIPS 'move' insn emulation

[Peter Maydell]

On 14 September 2017 at 15:23, Yongbok Kim <yongbok.kim@imgtec.com> wrote:
> The reason why your modification is failed is because you passed wrong
> argument. Remember that you are not just calling the helper function from
> translate.c but you are generating some code to let call the helper
> function on run time. You have to create a temporal TCGv to pass the
> register number.
> You could do it like,
> TCGv_i32 tmp = tcg_const_i32(rd)
> gen_helper_trace_reg_access(cpu_env, tmp, cpu_gpr[rs);
> tcg_temp_free_i32(tmp);

Good catch, missed that you need to do that for int
constants...

thanks
-- PMM

Re: [Qemu-devel] MIPS 'move' insn emulation

[Sergey Smolov]

On 14.09.2017 17:23, Yongbok Kim wrote:
>
> On 14/09/2017 15:16, Sergey Smolov wrote:
>> On 14.09.2017 16:58, Peter Maydell wrote:
>>> At translate time it is generating some extra code which at runtime
>>> will call the helper_trace_reg_access() function, passing it the
>>> values in the registers at this point. This will result in poor
>>> performance if you do it for frequently executed instructions.
> Yes indeed. it will be hitting the performance critically the instruction
> is quite often used. :)
>
>> Ok, thank you.
>>
>>> That looks like it ought to work. Check you really did save all your
>>> files in your editor before compiling? :-)
>> Yes, I did. These warnings are very suspicious, because they come with
>> strange numbers of MIPS GPR registers that I receive for my program.
>>
>> Here is the program:
>>
>> .text
>>      addiu $8, $zero, 0x7
>>      move $9, $8
>>      sll $8, $8, 3
>>      add $8, $8, $9
>>
>> Here is the log that helper functions provide:
>>
>> $0 00000007
>> $7 00000007
>> $0 00000038
>> $0 0000003f
>>
>> The first value is register name, the second is the value to be written.
>> Values are ok, but I expect to see $8 and $9  registers here.
>>
>>> PS: there's no point passing the env pointer into the function if
>>> you're not going to use it...
> Yes you're right. I had further use of the env but it has been chopped for
> the example.
>
>> I thought that I need to pass env pointer to helper function because of
>> some convention. Again, thank you for the note.
>>
> Sergey,
>
> The reason why your modification is failed is because you passed wrong
> argument. Remember that you are not just calling the helper function from
> translate.c but you are generating some code to let call the helper
> function on run time. You have to create a temporal TCGv to pass the
> register number.
> You could do it like,
> TCGv_i32 tmp = tcg_const_i32(rd)
> gen_helper_trace_reg_access(cpu_env, tmp, cpu_gpr[rs);
> tcg_temp_free_i32(tmp);
>
> or simply use the predefined macro and fix the order of the arguments.
>
> gen_helper_0e1i(trace_reg_access, cpu_gpr[rs], rd);
>
> Regards,
> Yongbok

It helps!

Thank you both for detailed explanations:-)

-- 
Sincerely yours,
Sergey Smolov