Use the actual written address range in DC ZVA's memory operand

[derekbruening]

Unlike the other DC cache operations, DC ZVA is not a cache management
operation but more of a regular store instruction. But clients analyzing
it need its actual start address (back-aligned) and size (cache line size).
The easiest thing for a client would be to have that in the IR operand,
instead of the encoded address: though that brings up issues of re-encoding
fidelity (xref #3339).

[abhinav92003]

Another complexity with the existing handling of DC ZVA:
it is currently counted as a load operation, as specified by the codec here:

dynamorio/core/ir/aarch64/codec.txt

Line 282 in d179619

1101010100001xxxxxxxxxxxxxxxxxxx sys : sysops memx0

I tried adding another codec rule, specific to DC ZVA, that considers memx0 as a destination instead. Something like
110101010000101101110100001xxxxx sys memx0 : sysops
but the pattern overlaps with the existing pattern for sys

We might have to either:

1. improve the codec to allow overlapping patterns: in case of ambiguity, give precedence to the first matching one.
2. split the pattern for sys into multiple mutually exclusive patterns for its variants.(127 variants: https://developer.arm.com/docs/ddi0595/h/aarch64-system-instructions)

[derekbruening]

We might have to either:

1. improve the codec to allow overlapping patterns: in case of ambiguity, give precedence to the first matching one.
2. split the pattern for sys into multiple mutually exclusive patterns for its variants.(127 variants: https://developer.arm.com/docs/ddi0595/h/aarch64-system-instructions)

Improving the codec is #4393, and splitting up SYS is a key motivator for doing so.

[abhinav92003]

The easiest thing for a client would be to have that in the IR operand,
instead of the encoded address

Just checking my understanding: this IR change would require adding a new member in _opnd_t to denote back-alignment, here:

dynamorio/core/ir/opnd.h

Line 1413 in 0762e11

} value;

and then use this in

dynamorio/ext/drutil/drutil.c

Line 385 in 0762e11

drutil_insert_get_mem_addr_arm(void *drcontext, instrlist_t *bb, instr_t *where,

during the address calculation right?

Also,
the aarch64 codec needs to do this back-alignment for not all SYS operations; currently it's needed only for DC ZVA and maybe flush operations. Therefore, it seems #4393 is a blocker for this issue, right? If yes, I can try working on #4393.

[derekbruening]

No, rather than inventing a new kind of operand, we would simply discard the original address and store a base+disp equal to what is actually referenced, treating the encoded address as just an encoding detail. That is what I wrote: instead of the encoded address. And that is why I mentioned the (minor) downside of re-encoding fidelity (xref #3339) b/c of the lost info on a modified instruction.

Any scheme using the actual linear address range affected in the IR also has the problem that the decoder now has to know the cache line size, bringing up cross-machine and cross-arch decoding consistency issues.

[derekbruening]

Any scheme using the actual linear address range affected in the IR also has the problem that the decoder now has to know the cache line size, bringing up cross-machine and cross-arch decoding consistency issues.

I guess we would make this a decoder setting like the ISA mode (dr_get_isa_mode()) and add routines for setting it? The alternative is to leave the original address there as part of some new type of operand, forcing updates to all operand handling code to handle the new type, hoping to defer the cache line size evaluation to instrumentation where we are less likely to support cross-machine operation and where the underlying line size being used is reasonable.