[Soot-list] variable name conflict

[Sergio Ferrero]

Hi Eric,

I'm sorry that I'm not being clear enough.
I'll try to be clearer on what I'm doing by providing some more context.

Part of a project I'm working on requires to generate Jimple files out of
an apk (I use Soot for this) and then visualize the jimple file in an
Eclipse Editor.
The editor must be backed-up by a Jimple AST or Jimple IR objects. The
editor should provide features like Mark Occurrences and Open Declaration.
So, given a selection in the Editor I should be able to find the
corresponding AST node or Jimple object.
For example: if the text selection is on a local declaration, then I should
get the corresponding JimpleLocal object and get all the places (Boxes)
where that JimpleLocal is defined/used. Im able to locate a JimpleLocal
since I have added source correspondence for all Jimple objects.

I'm using the Jimple parser to create a Jimple AST (classes in
soot.jimple.parser.node) and then invoking Walker.java to create the
in-memory representation of the jimple file (classes are in soot.jimple and
soot.jimple.internal).
I prefer to work with this in-memory representation instead of the Jimple
AST since it provides some methods that are useful, e.g. getUseAndDefBoxes()

So, the problem I face is that once I have the Jimple IR objects created
out the jimple file that redefines variable x in 3 different blocks, if I
check all use and def boxes for the local variables, only the last variable
definition is the one taken into account, that is "int x". The other
definitions of "x" are never use in any value box.

Now that you mentioned "I can see that it looks odd, though, when the code
is printed." I wonder whether this is a problem I won't be able to solve,
since my analysis is based on parsing a Jimple file in order to get a
Jimple IR in memory, and by parsing the Jimple file Soot (actually
Walker.java) cannot accurately relate declarations and usage for each
variable x.


I hope this makes things clearer and helps identify what is being done
wrong if anything.

Thanks
Sergio




On Fri, Jul 12, 2013 at 5:22 AM, Bodden, Eric <eric.bodden at sit.fraunhofer.de
> wrote:

> I am sorry but I fail to see the problem. Can you please explain it again?
>
> From what I can see, there are three *different* locals that happen to
> have been assigned the same name. In the object representation of Jimple
> this should be no problem. (I can see that it looks odd, though, when the
> code is printed.)
>
> Cheers,
> Eric
>
>
> On 04.07.2013, at 19:17, Sergio Ferrero <sferrero at ensoftcorp.com> wrote:
>
> >
> > I found that Soot does not properly support the case in which the same
> variable name is declared in different java blocks.
> >
> > I created an example in which a variable named "x" is used in different
> blocks:
> >
> > package soot.test;
> >
> > public class Locals {
> >       public void testDeclarations() {
> >
> >               // Block 1
> >               {
> >                       String x = "hello";
> >               }
> >
> >               // Block 2
> >               {
> >                       char x = 'a';
> >               }
> >
> >               // Block 3
> >               for (int x = 0; x < 10; x++) {
> >
> >               }
> >       }
> > }
> >
> > I generated Jimple code using the Soot's eclipse plugin by right
> clicking on the file and selecting
> > "Soot->Process Source File->Create Jimple"
> >
> > The generated Jimple code redefines the variable with the same name
> three times in the method body. If I check all use and def boxes for the
> local variables, only the last variable definition is the one taken into
> account, that is "int x". The other definitions of "x" are never use in any
> value box.
> > Below is the Jimple code for the testDeclarations() method.
> >
> >     public void testDeclarations()
> >     {
> >         soot.test.Locals this;
> >         java.lang.String x;
> >         char x;
> >         int x, temp$0, temp$1;
> >
> >         this := @this: soot.test.Locals;
> >         x = "hello";
> >         x = 97;
> >         x = 0;
> >
> >      label0:
> >         nop;
> >         if x < 10 goto label1;
> >
> >         goto label2;
> >
> >      label1:
> >         nop;
> >         nop;
> >         temp$0 = x;
> >         temp$1 = temp$0 + 1;
> >         x = temp$1;
> >         goto label0;
> >
> >      label2:
> >         nop;
> >         return;
> >     }
> >
> > Is this a bug in Soot or is there any Soot option I need to change to
> properly support this use case?
> >
> > Thanks
> > Sergio
> >
> > _______________________________________________
> > Soot-list mailing list
> > Soot-list at sable.mcgill.ca
> > http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
> --
> Prof. Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
> Head of Secure Software Engineering  at Fraunhofer SIT, TU Darmstadt and
> EC SPRIDE
> Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20130712/1c553a8e/attachment.html