[Soot-list] Getting line-number/type-informations at initialization via Jimple from bytecode

[Tillmann]

Hi,

it's me again. I found out that there is possible a failiure in the CFG 
processing

if(!Util.v().useFaithfulNaming || la == null) in lines 891 & 920 
@soot.coffi.CFG.java

in my opinion must be without "!" -> if(Util.v().useFaithfulNaming || la 
== null). I've tried this and the names from local variable table are 
allocated correctly in "name"! But unfortunately i got Exceptions 
afterwards because the names obviously aren't connected properly :(

java.lang.RuntimeException: Variable r4 used without definition!
     at 
soot.jimple.toolkits.scalar.CopyPropagator.internalTransform(CopyPropagator.java:145)

by following the useFaithfulNaming variable i also altered the negation:

if(!useFaithfulNaming && activeVariableTable != null) in 
getLocalForIndex(JimpleBody listBody, int index) @soot.coffi.Util in 
line 817.

Afterwards everything seemed to be okay (the name switched from "l0" to 
"realVariableName"), but in internalTransform() in my jtp.x-pack the 
JimpleBody looks like before (names are: r0, r1, ...) .

Regards.

Tillmann


Am 13.12.2011 13:40, schrieb Tillmann:
> Hi Eric,
>
> thanks for your quick response.
>
> I've tried "Options.v().setPhaseOption("jb","use-original-names:on");"
> the option seems to be applied correctly (is set in
> "soot.coffi.CoffiMethodSource.getBody(SootMethod, String)"), but with no
> effect on the jimple-bodies. The Bytecode is compiled with names (see
> below - gathered from eclipse-class-inspection).
>
> But it's not a huge amount of work for me to create a work-around in my
> source-transformation-process.
>
>         0  iconst_0
>         1  istore_2 [flag]
>         2  aconst_null
>         3  astore_3 [client]
>         4  aconst_null
>         5  astore 4 [home]
>
> Am 13.12.2011 12:35, schrieb Eric Bodden:
>> Hi Tillmann.
>>
>> One thing you could try is to use "-p jb keep-original-names:on". This
>> will cause Soot to try to pack together locals that have the same
>> name.
>>
>> In general, the problem you are seeing is caused by the fact that
>> bytecode has no local variables, just stack locations.