Incorrect operand type in google server workload traces

[York Ma]

Hi,

I am investigating register operand dependencies in the google server workload
traces.
It seems that the trace records (memref_t) are successfully decoded into instr_t
and x86 register IDs are obtained.
However, the operand type does not make sense: most of the destination operands
(also the 2nd source operand) appear to be memory references but I think most of
them should be register operands.
I am wondering whether there is some bugs in my decoding process or in the
generated trace.

Here's my code to decode operands (opnd_t).
    auto decode_operand = [](opnd_t opd) -> Operand {
        Operand opd_rec;
        if (opnd_is_memory_reference(opd)) {
            opd_rec.type = OperandType::Memory;
            opd_rec.base_reg = opnd_get_base(opd);
            opd_rec.index_reg = opnd_get_index(opd);
            opd_rec.displacement = opnd_get_disp(opd);
        }
        else if (opnd_is_immed(opd)) {
            opd_rec.type = OperandType::Immediate;
        }
        else if (opnd_is_reg(opd)) {
            opd_rec.type = OperandType::Register;
            opd_rec.regid = opnd_get_reg(opd);
        }
        else {
            opd_rec.type = OperandType::Others;
        }
        return opd_rec;
    };

And the attached figure is the decoded trace records.

Register operands are show as reg:<reg_name> and memory references are shown as
mem:<base_reg>:<index_reg>:<offset>.
The log is from decoding the four traces (from delta) (via the scheduler):
13110814307995660531.636438.memtrace.zip
13110814307995660531.636440.memtrace.zip
13110814307995660531.636439.memtrace.zip
13110814307995660531.636441.memtrace.zip

The trace looks make sense if we ignore the operand type.
Most of instructions have two source operands and one source is also the
destination.
The instructions frequently use registers RAX, RCX, RDX, or RBX.
All these features match what I expected from an x86 instruction trace.
But the operand type of the destination operand (and also the 2nd source operand)
looks not correct.
The log shows that most of the destinations are memory references.
However, I think most of them are simply register operands since the underlying
instruction record is not followed by a memory record.
Am I decode the operands in a correct way?

[Kai Luk]

The trace is using the DR_ISA_REGDEPS synthetic ISA. Please refer to https://dynamorio.org/google_workload_traces.html#sec_google_format and https://dynamorio.org/dr__ir__encode_8h.html#a00e03b2e5e75a83eacf9a0ee1674074aa1bbcfa1df3fffff3d96b357f9a2290d3 for details. 

For example, you can use decode() https://dynamorio.org/dr__ir__decode_8h.html#a5ca2a278008e547130218e8cfde44e3d to docs the instructions.

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dynamorio-users/232434b7-8105-4de5-bd0f-eb0bd437cbf5n%40googlegroups.com.

[Derek Bruening]

Use the view tool for a human-readable view of the virtual registers used by each instruction.

For a new tool, as documented, use the decode_cache_t library which does the heavy lifting for you.

To view this discussion visit https://groups.google.com/d/msgid/dynamorio-users/CACpA1zG%3D_u89jPs7P-CFoUABwKCJcu%3Dbptq-1iYqvDiZbTRVFA%40mail.gmail.com.