[Soot-list] summary of 2013 SOAP workshop discussions

[Quentin Sabah]

> The "use-original-names" option probably uses the optional class file
> attribute LocalVariableTable to map variable names to their slots. This
> same attribute also has, for every local variable, a "start_pc" and
> "length" which can be used to determine the range of instructions over
> which the variable is in scope.
>
> This information might be useful in things like differentiating
> distinct variables with the same name and same type but in different
> scopes, as well as maybe a crude indication of live ranges.

This is currently how the functionality is implemented. But the table 
might be incorrect (we've seen some examples recently) and it shouldn't 
be trusted to generate actual variables in Soot nor be employed for any 
other analysis though.

Currently, if the LocalVariableTable gives several names for the same
variable slot in overlapping scopes, Soot will generate several 
variables, which is unsound. Similarily, if the table report the name of 
a variable only for a fraction of its actual scope, two distinct 
variables will be generated, which again is unsound.

The proper approach is to trust only the bytecode to generate variables 
(like when use-original-names is disabled), and then have a relation 
from variable to original name(s). If a variable is associated only one 
name in the relation then we can conclude it is most probably the good 
one. If a variable is associated more than one name, then the 
LocalVariableTable might be unsound.

-- 
Quentin Sabah, CIFRE Ph.D. student
Grenoble University
INRIA-SPADES                   | STMicroelectronics/AST
Montbonnot, France             | Grenoble, France
mailto:quentin.sabah at inria.fr  | mailto:quentin.sabah at st.com
phone: +33 476 61 54 57        | phone: +33 476 58 44 14