|
|
|
| Authored by: bugstomper on Tuesday, May 15 2012 @ 11:46 AM EDT |
I could be confused about the example being talked about, but notice where the
01 is being called a field index.
The Dalvik iget instruction takes an argument of the form TTTT@CCCC where TTTT
is one of a few strings, one of which is "Field", and CCCC is a hex
number. When the operand is of the form Field@CCCC then CCCC represents a
numeric offset into the Field Table. That CCCC value is called in the
documentation a "field index". The Field Table is an array of
elements, each of which has three items. The first is an index into a Class
table, and identifies which class is being referenced. The second item is an
index into the Constant Pool pointing to a string constant that is the name of
the field in the class. The third item is a similar reference to a string that
is the type descriptor of the field.
iget Field@0001 is referring to the first element of the Field Table. That first
element will point to a class, and a string such as "y" and a type
descriptor. The iget instruction will look up the field named "y" in
that class and get the data in that field. That lookup requires a symbol
resolution step. The code I found that does it loops through the list of fields
in the class doing a string compare with the string that the Field Table entry
points to until it finds a match, then returns a pointer to the field that it
found.
I agree that Dalvik does not practice the claim, but the only basis for saying
that is that the Court has stated a construction that limits the claim to doing
the resolution "dynamically" at runtime, and dexopt does it statically
before the instruction is executed.[ Reply to This | Parent | # ]
|
|
|
|
|
