[Soot-list] Class resolving with Soot

Sun Jan 6 10:38:51 EST 2013

While I agree with Bernhard that letting Soot do the hard work for you 
is a good idea, there may be some reasons why you would prefer not to do 
so. One could be that you want to learn something, or that you feel like 
Jimple would create too verbose C.

The standard method in the compiler world is to use a symbol table. For 
what you are trying to do, the symbol table is populated from 
java.lang.* and the imports. You can pick up the imports from the file 
and use that to resolve your references. But that means really working 
in the Java-to-Jimple phase, with APIs that few people here know.

By the way, what is your real final objective? Do you want C, or native 
code? Maybe you can code a back-end to generate the native code from the 
IR. This is going to be a lot of work, but I'm trying to give options :D

Also, note that there are IRs that work for many languages - I am 
thinking of the Gimple IR of GCC. Maybe such a platform would work 
better for what you're trying to do.

Marc-André Laverdière-Papineau
Doctorant - PhD Candidate

On 13-01-04 06:08 PM, Yi Lin wrote:
> Hi,
>
> I turned off -allow-phantom-refs.
>
> I am prototyping a Java-to-C translator. So when I am parsing Java
> source code and encounter a Class name (e.g. "String"), I ask Soot for
> its information. If soot cannot load this class, I will check the
> imports or java.lang.String to get a full class name, then try load with
> Soot. In this case, Soot works fine, since I won't ask soot to load
> class with the same name twice. However, if I meet "String" again, and
> ask Soot for it, Soot would return a 'fake' SootClass to me and I am not
> able to tell the resolving actually fails. So currently I am storing a
> map for <class name, SootClass> pair, and I will check the map before I
> ask Soot for a class. But I am not quite comfortable with this, since I
> assume Soot is already maintaining such a map for all the resolved
> classes and I am just complicating that. Maybe this doesn't matter...
>
> Regards,
> Yi
>
> On 4/01/2013 11:05 PM, Bernhard Berger wrote:
>> Hi Yi,
>>
>> have enabled -allow-phantom-refs? BTW: What do you want to do? It seems that you are asking for a class Soot cannot load/find and signals it with a RuntimeException. You catch the exception and continue with your program as if there were no error.
>>
>> Bernhard
>>
>>
>> Am 04.01.2013 um 12:56 schrieb Yi Lin <qinsoon at gmail.com>:
>>
>>> Hi,
>>>
>>> Thank you for the explanation.
>>>
>>> So I tried resolvingLevel() and isInScene() on the returning SootClass object. The resolvingLevel() is 3(BODIES) instead of 0(DANGLING). And isInScene() returns true. This means I still have no way to tell that this class isn't actually found by Soot.
>>>
>>> Regards,
>>> Yi
>>>
>>> On 4/01/2013 10:39 PM, Bernhard Berger wrote:
>>>> Hi,
>>>>
>>>> if you look into the source of SootResolver you will find that SootResolver.resolveClass calls SootResolver.makeClassRef. There the scene is asked whether it contains the class.If it is not in the scene it creates a new SootClass with level DANGLING and adds it to the scene. Afterwards, somewhere in SootResolver.processResolvingList soot tries to bring it to another level but fails and throws the exception. The second time you call the method Soot is able to find the dangling SootClass and returns it.
>>>>
>>>> Regards,
>>>>
>>>> Bernhard
>>>>
>>>>
>>>> Am 04.01.2013 um 12:20 schrieb Yi Lin <qinsoon at gmail.com>:
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> Yes, on the second call, I can get a SootClass object with the class
>>>>> name (e.g. "String"), but with empty package name, no methods, etc. I
>>>>> assume the class resolving still fails, however, these information
>>>>> cannot definitely tell that the class resolving fails. I would expect
>>>>> that the second call could raise the same exception as the first call so
>>>>> that I can know that the class is still not found. Is there any other
>>>>> class resolving APIs that I can try with?
>>>>>
>>>>> Thank you very much.
>>>>>
>>>>> Regards,
>>>>> Yi
>>>>>
>>>>> On 4/01/13 21:58 , Eric Bodden wrote:
>>>>>> Hi Yi.
>>>>>>
>>>>>> What happens on the second call? Do you actually get a SootClass object?
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>> On 4 January 2013 03:15, Yi Lin <qinsoon at gmail.com> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I am trying to use either Scene.v().forceResolve() or
>>>>>>> SootResolver.v().resolveClass().
>>>>>>>
>>>>>>> However, if I give a wrong class name, e.g. "String" instead of
>>>>>>> "java.lang.String", calling either of the methods above would cause a
>>>>>>> runtime exception saying "couldn't find class: String". However, next
>>>>>>> time when forceResolve() or resolveClass() is called with "String" in
>>>>>>> the same run, no exception is raised. So in this case, is it possible
>>>>>>> for me to tell that the resolving fails?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Yi
>>>>>>> _______________________________________________
>>>>>>> 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
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>