[Soot-list] How to get field object in Jimple code?

[Sai Zhang]

Probably, that is the reason: I note the following code:


public class ImmediateBox extends AbstractValueBox
{
    .....................
    public boolean canContainValue(Value value)
    {
        return value instanceof Local ||
            value instanceof Constant;
    }
}


So passing a JInstanceRef could be problematic.... but I am still
not so clear about why.

thanks

-Sai





On Wed, Apr 28, 2010 at 9:32 AM, Sai Zhang <racezhang at gmail.com> wrote:

> Hey Eric:
>
> Thanks for your answer.
>
> I am sorry that I did not make it clear about my question.  Propably the
> sentence
> "decide a2.s and a1.s are pointing to the same memory locatio"  is too
> misleading.
>
>  In one sentence,  I am not clear about how to use Soot's API to get the
> field object
> in a JInstanceRef  instance. Let's continue with the following example:
>
>
> > //(roughly) corresponding jimple code for client code
> > 1.   $r1 = new A;
> > 2.   r2 = $r1
> > 3.   r2.<A: string s> = "hello";
> > 4.   r3 = $r1
> > 5.   r3.<A: string s> = "world"
>
>
> Line 5, r3.<A:string s> is a JInstanceRef object (Value type), but when I
> insert the following
> instrumentation code for profiling:
>
> units.insertBefore(Jimple.v().newInvokeStmt(
>
> Jimple.v().newStaticInvokeExpr(traceCall.makeRef(),
>                                         Arrays.asList(new Value[]
> {r3.<A:string s>, StringConstant.v(field.toString())}))), s);
>
> The traceCall is a method with the following signature:  (Object, String,
> Object)
>
>
> An exception during profiling was thrown:
>
> (NewRep and i is the class name and field name)
>
> Exception in thread "main" java.lang.RuntimeException: Box VB(null) cannot
> contain value: $r1.<NewRep: int i>(class
> soot.jimple.internal.JInstanceFieldRef)
>     at soot.AbstractValueBox.setValue(AbstractValueBox.java:42)
>     at soot.jimple.internal.ImmediateBox.<init>(ImmediateBox.java:40)
>     at soot.jimple.Jimple.newImmediateBox(Jimple.java:861)
>     at
> soot.jimple.internal.JStaticInvokeExpr.<init>(JStaticInvokeExpr.java:45)
>     at soot.jimple.Jimple.newStaticInvokeExpr(Jimple.java:433)
>
>
>
> So I guess i use an incorrect way to get the field object.
>
> Hope I have stated that clearly now.
>
> thanks
>
> -Sai
>
>
>
>
>
> On Wed, Apr 28, 2010 at 3:17 AM, Eric Bodden <
> bodden at st.informatik.tu-darmstadt.de> wrote:
>
>> Hi.
>>
>> I think in general you are interested in points-to analysis or alias
>> analysis.
>>
>> Soot has a local must-alias analysis:
>>
>> http://www.sable.mcgill.ca/soot/doc/soot/jimple/toolkits/pointer/LocalMustAliasAnalysis.html
>>
>> That can tell you whether two local variables must point to the same
>> object.
>>
>> Eric
>>
>> --
>> Dr. Eric Bodden
>> Software Technology Group, Technische Universität Darmstadt, Germany
>> Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
>> Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt
>>
>>
>>
>> On 28 April 2010 01:57, Sai Zhang <racezhang at gmail.com> wrote:
>> >
>> > Hi all:
>> >
>> > I am a bit confused on how to extract "field object" from Jimple code
>> (used
>> > in a field-sensitive dynamic analysis).
>> >
>> > For instance, consider the following simple class and the corresponding
>> > jimple code:
>> >
>> > class A {
>> >   Object s  = "string";
>> > }
>> >
>> > //client code:
>> > A a1 = new A();
>> > a1.s = "hello";
>> > A a2 = a;
>> > a2.s = "world";      // a2.i should be the same field as a1.i
>> >
>> >
>> > //(roughly) corresponding jimple code for client code
>> > 1.   $r1 = new A;
>> > 2.   r2 = $r1
>> > 3.   r2.<A: string s> = "hello";
>> > 4.   r3 = $r1
>> > 5.   r3.<A: string s> = "world"
>> >
>> >
>> > Is there a way to fetch the object of "A.s" (not the field reference,
>> e.g.
>> > SootField , SootFieldRef) from line 3 and line 5?
>> >
>> > For instance, could I could insert some instrumentation code after line
>> 5,
>> > like:
>> > Tracer.record( .....r3.<A:string s> (// get the object of A.s),...);
>> >
>> >
>> > In other words, is there anyway to decide a2.s and a1.s are pointing to
>> the
>> > same memory location in a dynamic analysis? In my intuition,
>> > it should not be that hard, since r2 and r3 seem to share the same
>> > JimpleLocal object, right? but how to get the state of "A.s" seems
>> > to be a problem. Is there any good way to overcome that? or am i in a
>> wrong
>> > direction?
>> >
>> >
>> > Thanks so much.
>> >
>> >
>> > - Sai
>> >
>> > _______________________________________________
>> > Soot-list mailing list
>> > Soot-list at sable.mcgill.ca
>> > http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>> >
>> >
>>
>
>
>
> --
> --
> Sai Zhang
> Computer Science & Engineering Department
> University of Washington, Seattle, USA
> Email: (saizhang at u.washington.edu)
>



-- 
--
Sai Zhang
Computer Science & Engineering Department
University of Washington, Seattle, USA
Email: (saizhang at u.washington.edu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20100428/2b69274d/attachment.html