[Soot-list] Linking Jimple code to Java code for capture-and-replay

[Sai Zhang]

Thanks Humberto.

Well, I think keeping the source code line might not be a perfect choice,
since there could be
multiple variables in the same line.  Need more tricks to figure out which
var is the needed one.

On Mon, Apr 26, 2010 at 5:09 AM, Humberto sousa pacheco <
humbertocin at gmail.com> wrote:

> Hello,
> I think, the line from the source code where the variable is, could be used
> to make this linking (as well as its start position into the line).
>
>
> On Mon, Apr 26, 2010 at 4:48 AM, Eric Bodden <
> bodden at st.informatik.tu-darmstadt.de> wrote:
>
>> Hello Sai.
>>
>> If you use -p jb use-original-names:on then you should be getting
>> Jimple variables that have the same names as the original variables in
>> source code.
>>
>> However, I am not sure if you even need this. After all, you could
>> just encode parameter names through numbers (param0, param1, ...), and
>> for fields you could just use their proper names, e.g.
>> "SomeClass.StaticField" (those are preserved in Jimple).
>>
>> What may be more of a problem is that you may need to store also the
>> location at which a value was loaded. After all, what do you do if a
>> method contains multiple statements "b =  SomeClass.StaticField" or is
>> such a statement is contained in a loop?
>>
>> 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 26 April 2010 09:22, Sai Zhang <racezhang at gmail.com> wrote:
>> > Hey all:
>> > I am wondering is there a convenient way to link Jimple code to Java
>> code
>> > at the variable-level? For instance, in implementing a capture-replay
>> tool,
>> > we need to record (capture) the current object states and recover that
>> in
>> > the replay phase. Thus, it could need to "link jimple code to Java
>> code".
>> > (i could be wrong on this point)
>> > For instance,  consider a simplest example as follows:
>> > public void m(object arg1, object arg2) {
>> > Object b =  SomeClass.StaticField;  (or a global field)
>> > // for a capture and replay tool, we need to
>> > //save the state of object "this", "arg1", "arg2", and
>> > "SomeClass.StaticField"
>> > }
>> > When implementing such a tool using Soot, "this", "arg1", "arg2"...
>> > will be translated into r0, r1, r2 ... (JImpleLocal vars). In such
>> cases,
>> > how could we save the original states of  "this, arg1, arg2" and the
>> global
>> > field?
>> > That is how to link the jimple code (JimpleLocal) to the actual java
>> code?
>> > Merely saving the states of r0, r1, r2 seems to be not a perfect
>> solution.
>> > PS. Is there any publicly available capture-and-replay tools implemented
>> > based on Soot?
>> > Thanks a lot.
>> >
>> > --  Sai
>> >
>> > _______________________________________________
>> > Soot-list mailing list
>> > Soot-list at sable.mcgill.ca
>> > http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>> >
>> >
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>
>
>
> --
> Humberto S. Pachêco - hsp
> Monitor de Informática Teórica
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20100426/51beaa19/attachment.html