summaryrefslogtreecommitdiff
path: root/test/ProfileTestMultiDex
diff options
context:
space:
mode:
authorSebastien Hertz <shertz@google.com>2014-07-16 11:56:07 +0200
committerSebastien Hertz <shertz@google.com>2014-07-24 14:18:10 +0200
commit5dc158e9b6635b6c5d3916ae4094e8886feb4580 (patch)
tree0f977d9b93fd6dc4eb642cfe894a3561c2155c09 /test/ProfileTestMultiDex
parentbebee4fd10e5db6cb07f59bc0f73297c900ea5f0 (diff)
Fix access to long/double stack values from debugger
Long and double values live in a pair of DEX registers. When we compile DEX code with the Quick compiler, a DEX register either lives in the stack or is promoted to a physical register. In the case of a pair of DEX registers, the Quick compiler assumes both registers live in the same "area": both live in the stack or both are promoted to physical registers. From the debugger, we used to access these values by reading/writing each DEX register separately. However, this does not work when only one DEX register of a pair is promoted and the other lives in the stack. In this case, the compiled code reads from/writes to the stack only. To fix that, the debugger must follow the same rule than the Quick compiler: if both DEX registers are promoted, read/write them from/to physical registers, otherwise read/write them from/to the stack. We add StackVisitor:GetVRegPair and StackVisitor:SetVRegPair for this purpose. We also follow the same rule when deoptimizing. However we need to do that only when we know two consecutive DEX registers are part of a pair (long or double). We know that thanks to the verifier. Bug: 15527793 (cherry picked from commit c901dd7bdc80b953d04100ef2f54b8d1ca5f466b) Change-Id: I981e088295254d75352f83a3e6ba0b292cfe3ed3
Diffstat (limited to 'test/ProfileTestMultiDex')
0 files changed, 0 insertions, 0 deletions