[Soot-list] Class resolving with Soot

Sun Jan 6 18:21:06 EST 2013

Hi,

thank you both. Your suggestions are really helpful to me.

I am branching my work to try use Soot also for parsing. I was not 
considering about Jimple mainly because I thought Jimple was stack based 
- in this case, the generated C code from Jimple would not only be too 
verbose but probably slow. But clearly I was wrong. I do not quite worry 
about the expressiveness or readability of the generated code, they are 
not desired to be human readable anyway. I hope translating from Jimple 
would make the prototyping work easier.

For the objective of this work, we had a workshop paper discussing it 
[1]. To make it short, we try to define a variant of Java that inherits 
most syntax from Java but is semantically extended and restricted so it 
can be a candidate for system programming. Such variant is desired to 
execute either on a modified JVM (so its extensions are supported) or as 
C/native code if no available JVM exists. The translator aims the latter.

The actual implementing work is pretty much just started. Any 
suggestions are welcome.

Regards,
Yi

[1]. http://dx.doi.org/10.1145/2414740.2414746

On 7/01/13 2:38 , Marc-Andre Laverdiere-Papineau wrote:
> 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
>>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list