[Soot-list] variable name conflict

[Sergio Ferrero]

Hello Eric,

Yes, I agree this is an issue about scopes.

I don't need to do any transformation on code.
I just need to show an apk (dex files) at a high level representation and
I'd like to use Jimple for this. I found Dexpler (origin/develop branch of
Soot) allows me to do this.

So, basically I'm writing a tool to transform dex files to a set of jimple
files and then provide an editor to visualize Jimple files.
I just call Soot's Main class to generate jimple files out of dex files.

I just want to extend the JimpleEditor (that comes with the Soot plugin)
capabilities and provide the Mark Occurrences feature.
It's to support the Mark Occurrences feature that I need to parse a Jimple
File and do some queries on the internal representation classes.

As part of my testing I decided I'd test how variable scopes were supported
by jimple, and that's why I created a simple java code that declares
variables with same name but different types in different blocks. When I
converted that java file to Jimple using Soot I expected that Soot will
detect this case and rename the variables so that there is no name
collision but that did no happen.
So, the question will be whether Soot could/will detect that there are
variables with same name and different scopes when generating Jimple files
and properly address them.


On another note. I found this problem occurs if I go from java to jimple.
However, the actual scenario in my case will be going from dex to jimple.
So, I decided to create a simple android app in which one method recreates
the problem of variables with same name in different blocks. I exported it
as an apk, and then used my tool to unpack the apk and generate jimple
files for it. I found the problem went away, because variable names now are
different. This is the jimple code I got:

   public void testDeclarations(boolean)

    {

        com.example.myfirstandroidapp.MyActivity $r0;

        boolean $z0;

        java.lang.String $r1;

        java.lang.StringBuilder $r2;

        java.io.PrintStream $r3;

        char $c0;

        int $i1;

...


So, it seems this might not be an as problematic issue as I thought.

Thanks
Sergio


On Fri, Jul 12, 2013 at 12:46 PM, Bodden, Eric <
eric.bodden at sit.fraunhofer.de> wrote:

> Hello.
>
> > 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.
>
> That sounds wrong but we need to see exactly what you are doing and how
> you are doing it. Can you submit a but report on Github with a test case
> attached that reproduces the problem?
>
> > 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.
>
> Well I guess that if you intend to show Jimple to the user somehow it
> might make sense to rename the locals to resolve the ambiguity visually.
> The problem is the scope I guess - Java source has different scopes when
> blocks are used but Jimple has no blocks and hence only a single scope.
>
> Best wishes,
> Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20130716/d7af4296/attachment.html