|
From: Carl E. L. <ce...@us...> - 2016-01-14 17:18:41
|
Valgrind developers:
I am working on support for the new Power instructions. There are some
instructions that access the 64 128-bit Vector Scalar Register (VSR)
file that I can't emulate with existing Valgrind Iops. So, I need to
add a new Iop for these instructions. The issue is that currently the
Power support in Valgrind only handles issuing instructions that access
the general purpose registers, the 32 64-bit floating point (FPR)
registers and the 32 128-bit Vector Registers (VR). Note, the hardware
actually maps the FPRs and VRs into subsets of the 64 VSR registers.
I am trying to figure out within Valgrind how the contents of a register
in the guest state is "copied" into the physical register on the target
register before executing the native instruction. Similarly, how the
contents of the physical register gets "copied" back to the guest state.
I understand the details on Power of generating a native instruction to
be executed, it is done in emit_PPCInstr (), host_ppc_defs.c. I think I
understand the code for the register allocater that selects a register
in Power register space. But I can't find where/how the contents of the
Power Guest register gets put into the a physical register before
executing the generated Power instruction.
I was expecting to see something within VEX that would generate native
loads of the arguments from the Guest register file into the host
registers, then the generated instruction followed by the generation of
a native store instruction from the register into the Guest register
file. I don't see any native load/store instructions to handle the
operands.
The other possibility is that the values for the registers is stored
along with the generated instructions in VEX but then in coregrind the
native instructions would be generated to load the registers and execute
the generated instruction for the Iop. I haven't found anything like
that either.
I am not sure where in Valgrind the generated native instructions are
actually issued. Anyway, if someone can outline how all this works and
where some of these things occur it would be a big help so I can figure
out the specifics on Power of extending support to native instructions
that use the VSRs. Thanks for your time.
Carl Love
|
|
From: Ivo R. <iv...@iv...> - 2016-01-15 21:04:15
|
2016-01-14 18:18 GMT+01:00 Carl E. Love <ce...@us...>:
> Valgrind developers:
>
> I am working on support for the new Power instructions. There are some
> instructions that access the 64 128-bit Vector Scalar Register (VSR)
> file that I can't emulate with existing Valgrind Iops. So, I need to
> add a new Iop for these instructions. The issue is that currently the
> Power support in Valgrind only handles issuing instructions that access
> the general purpose registers, the 32 64-bit floating point (FPR)
> registers and the 32 128-bit Vector Registers (VR). Note, the hardware
> actually maps the FPRs and VRs into subsets of the 64 VSR registers.
>
> I am trying to figure out within Valgrind how the contents of a register
> in the guest state is "copied" into the physical register on the target
> register before executing the native instruction.
Let me chime in a bit...
So it starts in the instruction selector (isel) which selects instructions
specific
to an architecture. These instructions need to perform the work of the
corresponding Iops.
They typically work on virtual registers.
For accessing guest state, IR uses GET, PUT (and others).
So for GET, instructions which perform loading a value from guest state
to a virtual register need to be selected here.
VEX framework then, based on the architecture description
from LibVEX_Translate(),
maps the virtual registers to host ones via mapRegs().
The emitor then encodes the host register into the instruction(s) emitted.
> Similarly, how the
> contents of the physical register gets "copied" back to the guest state.
>
See also libvex_ir.h, a paragraph starting at line 76:
76 Storage of guest state
77 ~~~~~~~~~~~~~~~~~~~~~~
78 The "guest state" contains the guest registers of the guest machine
79 (ie. the machine that we are simulating). It is stored by default
80 in a block of memory supplied by the user of the VEX library,
81 generally referred to as the guest state (area). To operate on
82 these registers, one must first read ("Get") them from the guest
83 state into a temporary value. Afterwards, one can write ("Put")
84 them back into the guest state.
85
86 Get and Put are characterised by a byte offset into the guest
87 state, a small integer which effectively gives the identity of the
88 referenced guest register, and a type, which indicates the size of
89 the value to be transferred.
...
> I understand the details on Power of generating a native instruction to
> be executed, it is done in emit_PPCInstr (), host_ppc_defs.c. I think I
> understand the code for the register allocater that selects a register
> in Power register space. But I can't find where/how the contents of the
> Power Guest register gets put into the a physical register before
> executing the generated Power instruction.
>
> I was expecting to see something within VEX that would generate native
> loads of the arguments from the Guest register file into the host
> registers, then the generated instruction followed by the generation of
> a native store instruction from the register into the Guest register
> file. I don't see any native load/store instructions to handle the
> operands.
>
Search for Iex_Get and Ist_Put in the isel for Power arch.
> The other possibility is that the values for the registers is stored
> along with the generated instructions in VEX but then in coregrind the
> native instructions would be generated to load the registers and execute
> the generated instruction for the Iop. I haven't found anything like
> that either.
>
This is VEX's job. Coregrind and Valgrind's analysis tools work only with
IR.
HTH, I.
|