diff options
| author | Sebastien Hertz <shertz@google.com> | 2014-07-16 11:56:07 +0200 |
|---|---|---|
| committer | Sebastien Hertz <shertz@google.com> | 2014-07-24 14:18:10 +0200 |
| commit | 5dc158e9b6635b6c5d3916ae4094e8886feb4580 (patch) | |
| tree | 0f977d9b93fd6dc4eb642cfe894a3561c2155c09 /test/ProfileTestMultiDex | |
| parent | bebee4fd10e5db6cb07f59bc0f73297c900ea5f0 (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
