DynamoRIO / DynamoRIO/dynamorio

Should upper bit zeroing of overlaid registers be modeled in DR's IR?

Open
#6,218 0 comments 0 reactions 0 assignees View on GitHub
Component-IR
Dominant language
C
Stars
3.2k
Forks
629
Avg merge
2d 18h
Merged PRs (30d)
30

Description

We were revisiting this decision to not model the upper bit zeroing in the IR as part of a users list discussion: https://groups.google.com/g/dynamorio-users/c/jzTHyiY4ZsA/m/l6VPPVVsAQAJ

The original issue was #1382 about sub-SIMD register sizes; seemed worth filing a fresh issue for this top bit zeroing revisti.

We may resolve that discussion by speeding up instr_zeroes_ymmh(); adding top bit behavior to the IR may remain an open topic. This includes not just upper SIMD bit zeroing but also GPR zeroing (write to EAX and it zeroes the top bits of RAX).

Our thoughts from a brief discussion:

+ Change register operand or add 2nd dest operand? ⇒ No
+ Add flag to operand or to instr_t? ⇒ instr_t b/c operational; do not expect 2 dests w/ diff behavior
- Set by decode; user sets for synthetic & encoder picks encoding
+ Only for SIMD or set flag for x86 GPRs? Make zeroing the default and then no flag? What about single-vector-element ops which preserve: all have to set flag (today using size to indicate sub-reg?)?
+ Aside: vzerupper should be in instr_zeroes_ymmh() too? => #6217
- Should vzeroall + vzeroupper have explicit operands?

Are there cases of the same opcode+opnds which can be encoded legacy or VEX?
If so, which one is picked?
Will it maintain re-encoding fidelity (xref #3339)?
=>
I believe all the 2-variant cases where the same operation can be encoded as legacy or vex actually have a different opcode for vex with a "v" prefix. E.g., OP_padd vs OP_vpadd. They do the same operation but have a distinct opcode.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.