[Soot-list] Soot changes method signature after de-compilation from jimple to java

Steven Arzt Steven.Arzt at cased.de
Wed Apr 30 11:18:29 EDT 2014


Hi Dacong and Souvik,

If you can confirm that this patch fixes the problem, can you please open up a pull request on Github?

Best regards,
  Steven

-----Ursprüngliche Nachricht-----
Von: soot-list-bounces at CS.McGill.CA [mailto:soot-list-bounces at CS.McGill.CA] Im Auftrag von Dacong Yan
Gesendet: Mittwoch, 30. April 2014 17:15
An: Souvik Pal
Cc: Soot Mailing List
Betreff: Re: [Soot-list] Soot changes method signature after de-compilation from jimple to java

Hi Souvik,

This is due to a minor problem with the particular way that dava prints class constants such as User.class. The method signature is actually not changed.

A simple test case is the following.

ClassConst.java:

public class ClassConst {
  public static void main(String[] args) {
    print(ClassConst.class);
  }

  static void print(Class c) {
    System.out.println(c);
  }
}

Run "soot -f d ClassConst", and look at the outputted sootOutput/ClassConst.java. You will see the same problem.

Suggested fix is to change src/soot/dava/DavaUnitPrinter.java
(https://github.com/dacongy/soot/commit/37a93bc87bf919b6fb53cd0952a0e2ff90375ff7).

Thanks,
Tony

On Wed, Apr 30, 2014 at 10:03 AM, Souvik Pal <write2souvikpal at gmail.com> wrote:
> Hi,
> First of all sorry for this late reply.
>
>
> On Tue, Apr 29, 2014 at 6:46 PM, Marc-André Laverdière 
> <marc-andre.laverdiere-papineau at polymtl.ca> wrote:
>>
>> Hi Souvik,
>>
>> First, Soot 2.3 is really really old. Have you given thought to 
>> upgrading to 2.5? Or even better, the cutting-edge development branch?
>
>
> Will definitely try to upgrade to latest version of soot. I hope that 
> the transition would be smooth.
>
>>
>> Second, I don't understand what you are asking for... what do you 
>> mean by 'original signature of the API'?
>
>
> Let me explain the problem in detail.
>
> I have a Java application that uses Hibernate (a popular ORM for Java) 
> for persisting objects in database. In Hibernate, on of the most 
> popular ways to retrieve an object from database (into memory) is by 
> using the API session.get. It takes the class of the user defined 
> object and the primary key or essentially the unique id of that object 
> as parameters. So the signature of this API is
>
> java.lang.Object get(java.lang.Class, java.io.Serializable)
>
> Now, my task is to analyse such java application which uses Hibernate 
> APIs and suggest possible optimization. Optimizations can be as simple 
> as live variable analysis or constant propagation. I need to reproduce 
> the java application with transformation embedded, i.e. with a few 'dead-codes'
> deleted or some lines of the code modified capturing the effect of 
> constant propagation.
>
> For this I am using SOOT. I am using Jimple as intermediate 
> representation, analysing the code, adding suitable transformation and 
> then decompiling the Jimple into Java. This is where the problem 
> arises. While converting the Java to Jimple, the java statement 
> containing the Hibernate API session.get changes as follows into Jimple statement.
>
> Java Statement:  User user1 = (User) session.get(User.class, 1); // 
> assume 1 as an the id of the User object to be retrieved
>
> Jimple Statement(s):
> $r1 = staticinvoke <java.lang.Integer: java.lang.Integer 
> valueOf(int)>(1)
>
> // User class is located in package testProject.hibernate.examples
> $r2 = interfaceinvoke session.<org.hibernate.Session: java.lang.Object
> get(java.lang.Class,java.io.Serializable) > (class 
> "testProject/hibernate/examples/User", $r1)
>
> In the decompiled program (using dava), the same Java statement appears as:
>
> User user1 = (User) session.get(class 
> "testProject/hibernate/examples/User",
> Integer.valueOf(1))
>
> So the first argument of the API changed from User.class to class 
> "testProject/hibernate/examples/User"
> Hibernate can not recognize this, and the re-written (optimize) java 
> program fails to compile.
>
> I am interested to know how can I get rid of this issue. Will 
> upgrading to latest SOOT version solve this issue?
>
> Thanks and regards.
>
>
>
>>
>> Marc-André Laverdière-Papineau
>> Doctorant - PhD Candidate
>>
>> On 04/29/2014 06:43 AM, Souvik Pal wrote:
>> > Hi all,
>> >
>> > I am new to soot. I am using soot (soot 2.3) to analyze simple 
>> > Hibernate programs.
>> >
>> > Hibernate *session.get* API requires a *java.lang.Class* and
>> > *java.io.Serializable* type arguments. However when I am 
>> > de-compiling the Jimple expressions into java, the API signature 
>> > changes and Hibernate can not recognize it.
>> >
>> > Example.
>> >
>> > *User aUser = (User) session.get(User.class, 1);* get transformed 
>> > to in the de-compiled program.
>> > *aUser = (User) session.get(class
>> > "path/to/class/User", Integer.valueOf(1));*
>> >
>> > The intermediate Jimple statements are
>> >
>> > *$r1 = staticinvoke <java.lang.Integer: java.lang.Integer
>> > valueOf(int)>(1)
>> > *
>> > *$r2 = interfaceinvoke session.<org.hibernate.Session: 
>> > java.lang.Object get(java.lang.Class,java.io.Serializable)>(class
>> > "**path/to/class/User**", $r1)*
>> >
>> >
>> > Please let me know what should I do to keep the original signature 
>> > of the API.
>> >
>> > Thanks and regards,
>> >
>> > --
>> > *Souvik Pal*
>> >
>> >
>> > _______________________________________________
>> > Soot-list mailing list
>> > Soot-list at CS.McGill.CA
>> > https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>> >
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at CS.McGill.CA
>> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>
>
>
>
> --
> Souvik Pal
> Student M. Tech.,
> CSE, IIT Bombay
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at CS.McGill.CA
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>



--
Dacong (Tony) Yan
Ph.D. Student
Computer Science and Engineering
The Ohio State University, Columbus
http://www.cse.ohio-state.edu/~yan
_______________________________________________
Soot-list mailing list
Soot-list at CS.McGill.CA
https://mailman.CS.McGill.CA/mailman/listinfo/soot-list



More information about the Soot-list mailing list