[Soot-list] Sideeffectanalysis

[Jochen Huck]

Hi again,

I already tried that. I get the following exception:
Exception in thread "Thread-4" java.lang.ClassCastException: 
soot.jimple.internal.JInvokeStmt cannot be cast to soot.util.Numberable
     at soot.util.ArrayNumberer.get(ArrayNumberer.java:47)
     at soot.util.JeddNumberer.get(JeddNumberer.java:35)
     at jedd.internal.Jedd.literal(Jedd.java:158)
     at 
soot.jimple.paddle.PaddleContextSensitiveCallGraph.edgesOutOf(PaddleContextSensitiveCallGraph.java:97)
     at 
soot.jimple.toolkits.pointer.SideEffectTagger.keyFor(SideEffectTagger.java:113)
     at 
soot.jimple.toolkits.pointer.SideEffectTagger.internalTransform(SideEffectTagger.java:170)
     at soot.BodyTransformer.transform(BodyTransformer.java:51)
     at soot.Transform.apply(Transform.java:104)
     at soot.BodyPack.internalApply(BodyPack.java:49)
     at soot.Pack.apply(Pack.java:124)
     at soot.PackManager.runBodyPacks(PackManager.java:779)
     at soot.PackManager.runBodyPacks(PackManager.java:454)
     at soot.PackManager.runBodyPacks(PackManager.java:373)
     at soot.PackManager.runPacks(PackManager.java:350)
     at soot.Main.run(Main.java:198)
     at soot.Main.main(Main.java:141)

Jochen

Am 04.03.2011 17:47, schrieb Eric Bodden:
> Oh now I see.
>
> If I am not mistaken then any Stmt can function as a context. At least
> that's what the type hierarchy suggests:
> http://www.sable.mcgill.ca/soot/doc/soot/Context.html
>
> So you can just pass in the Jimple statement I suppose.
>
> Eric
>
> On 4 March 2011 17:14, Jochen Huck<jochen.huck at student.kit.edu>  wrote:
>> No I am not using Spark and Paddle. Only the interface description of
>> Context says that a context is a Spark AllocNode in case of an
>> object-sensitive call graph. I only use Paddle and therefore only instances
>> of Paddle AllocNode will be available.
>> In a bodyTransformer I have (for the example code) "method=main" and
>> "unit=f1.inc()" and I want to query the call graph for the edge going out of
>> f1.inc(). If cg is the instance of ContextSensitiveCallGraph I get the
>> Iterator over all edges going out of f1.inc() by cg.edgesOutOf(context,
>> method, unit). But I don't know where i can get the context instance from. I
>> assume it somehow has to do with the pointsToSet of f1.
>>
>> Thanks again,
>> Jochen
>>
>>
>> Am 04.03.2011 17:05, schrieb Eric Bodden:
>>> So are you trying to use Spark and Paddle at the same time? That won't
>>> work.
>>>
>>> I have not used Paddle in a while but I think that paddle implements
>>> its own CallGraph subclass that accepts paddle AllocNode instances as
>>> input.
>>>
>>> As an alternative to using paddle you can also use the demand-driven
>>> context-sensitive points-to analysis "DemandCSPointsTo".
>>>
>>> Eric
>>>
>>> On 4 March 2011 16:54, Jochen Huck<jochen.huck at student.kit.edu>    wrote:
>>>> Thanks! This is what I thought too.
>>>> I've got a question according the ContextSensitiveCallGraph (cg): I will
>>>> need to know the call graph edges that go out of f1.inc().
>>>> Given the declaringMethod(main) and the unit(f1.inc()) I have to ask
>>>> cg.edgesOutOf(context, method, unit). But where do I get the context
>>>> from?
>>>> The description of the interface Context says that context is a Spark
>>>> AllocNode in the case of an object-sensitive call graph. Using Paddle I
>>>> would only have access to a Paddle AllocNode, right? Where do I get the
>>>> AllocNode from? I am a little confused...
>>>>
>>>> Jochen
>>>>
>>>>
>>>> Am 04.03.2011 16:38, schrieb Eric Bodden:
>>>>> Hi Jochen.
>>>>>
>>>>>
>>>>> If I am not mistaken then you are looking for a 1-object-sensitive
>>>>> analysis. I think Ondrej wrote a paper a while ago in which he found
>>>>> out that object-sensitivity usually works best and a context length of
>>>>> 1 is often sufficient - at least that's what I remember.
>>>>>
>>>>> Eric
>>>>>
>>>>> On 4 March 2011 14:42, Jochen Huck<jochen.huck at student.kit.edu>
>>>>>   wrote:
>>>>>> Hi,
>>>>>>
>>>>>> the current implementation of the sideeffectanalysis
>>>>>> (soot.jimple.toolkits.pointer.SideEffectAnalysis) is
>>>>>> context-insensitive
>>>>>> and therefore really imprecise. For
>>>>>>
>>>>>> class Foo {
>>>>>>      int i;
>>>>>>      public static void main(String[] args) {
>>>>>>          Foo f1 = new Foo();
>>>>>>          Foo f2 = new Foo();
>>>>>>          f1.inc();
>>>>>>          f2.inc();
>>>>>>      }
>>>>>>      public void inc() {
>>>>>>          i++;
>>>>>>      }
>>>>>> }
>>>>>>
>>>>>> it reports that f1.inc() and f2.inc() have the same dependencies, since
>>>>>> the analysis is context-insensitive.
>>>>>>
>>>>>> I would like to improve the precisson using Paddle. Which option (1cfg,
>>>>>> object-sensitive) would I need, that it is possible to infer that the
>>>>>> calls to inc() have no dependencies?
>>>>>> I will have to rewrite some methods of SideEffectAnalysis and
>>>>>> SideEffectTagger. Any suggestions how difficult that would be?
>>>>>>
>>>>>> Thanks,
>>>>>> Jochen
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Soot-list mailing list
>>>>>> Soot-list at sable.mcgill.ca
>>>>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>>>>
>>>
>>
>
>