Split dex_pc<->native_pc mapping table
First of 2 related CLs - this one moves to a split table, a future
CL will compress the table to save image space.
The current MappingTable mixes two flavors of entries: dex->pc and
pc(return address)->dex. The problem is that we can have two
entries with the same native pc address but two different dex pcs.
The reason is that when we go from native pc to dex, the native
pc is actually the return address from the previous call, whereas
when we go from dex to native pc, the mapping refers to the first
native instruction of the sequence.
Previously, the first entry in the mapping table was the number
of subsequent entries. That will remain the same, but now
the second entry will be a count of the number of entries in
the pc->dex section of the table. The difference between the
two counts gives us the number of entries in the following dex->pc
section.
Change-Id: Ibadb96cb50bf1f93e079dff3832130b9f9782723
diff --git a/src/exception_test.cc b/src/exception_test.cc
index 7303ac6..b82f8f7 100644
--- a/src/exception_test.cc
+++ b/src/exception_test.cc
@@ -47,7 +47,13 @@
fake_code_.push_back(0x70 | i);
}
- fake_mapping_data_.push_back(2); // first element is count of remaining elements
+ fake_mapping_data_.push_back(4); // first element is count
+ fake_mapping_data_.push_back(4); // total (non-length) elements
+ fake_mapping_data_.push_back(2); // count of pc to dex elements
+ // --- pc to dex table
+ fake_mapping_data_.push_back(3); // offset 3
+ fake_mapping_data_.push_back(3); // maps to dex offset 3
+ // --- dex to pc table
fake_mapping_data_.push_back(3); // offset 3
fake_mapping_data_.push_back(3); // maps to dex offset 3