[Soot-list] SootResolver.bringToX...

[Eric Bodden]

Thanks a lot Ondrej, that is quite helpful.

Good to know that somebody still remembers all these things :-)

Eric


> On 08/12/2011 8:35 AM, Ondrej Lhotak wrote:
>>
>> The design of coffi requires that in order to bring some class C up to
>> level N, you must *first* bring all classes that C references up to
>> level N-1. In order to know which classes C references, you need to
>> bring C up to level N-1.
>>
>> (In the above, the word "references" is overloaded: the definition of
>> what a class "references" changes depending on which level you are
>> trying to resolve it to.)
>>
>> The system of worklists is designed to implement these rather tricky
>> constraints.
>>
>> References can be recursive: C can reference C', and C' can also
>> reference C. The private bringToX methods are called from coffi when
>> resolving C. If they tried to resolve C' directly, then the process of
>> resolving of C' would then try to recursively resolve C, and you would
>> have infinite recursion.
>>
>> The original Raja/Clark design of coffi and the SootResolver required
>> that you resolved all known classes to SIGNATURES first. It was then
>> safe to resolve any class of interest to BODIES. As class libraries grew
>> larger, resolving *everything* to SIGNATURES got very slow. (As well,
>> phantom classes were needed vrey frequently.) Running Soot on a single
>> class, even in non-whole-program mode, could easily take 30 seconds or
>> more. This was deemed unacceptable for the abc project. The options
>> were to rewrite coffi from the ground up (and possibly even change the
>> Jimple IR), or to build this complicated resolver to work around the
>> limitations of coffi's original design. We settled on the second option.
>>
>> The -full-resolver option brings back the old resolve-everything
>> algorithm, if you're feeling nostalgic...
>>
>>
>> On Wed, Dec 07, 2011 at 10:05:27AM +0100, Eric Bodden wrote:
>>>
>>> Hi all.
>>>
>>> Today it's me who has a question :-)
>>>
>>> I am having some students working on the SootResolver, and by looking
>>> at the code I am getting more and more confused. I always thought that
>>> the design was quite simple:
>>>
>>> - bringToHierarchies loads a class up to its super classes and interfaces
>>> - bringToSignatures loads methods and field signatures
>>> - bringToBodies fills in the bodies
>>> - All three methods load dependency classes to the required (lower
>>> levels).
>>>
>>> But apparently, this is not quite the case. For instance, we find this
>>> code in bringToSignatures:
>>>
>>>     private void bringToSignatures(SootClass sc) {
>>>         if(sc.resolvingLevel()>= SootClass.SIGNATURES ) return;
>>>         bringToHierarchy(sc);
>>>         sc.setResolvingLevel(SootClass.SIGNATURES);
>>>
>>>         for( Iterator fIt = sc.getFields().iterator(); fIt.hasNext(); ) {
>>>             final SootField f = (SootField) fIt.next();
>>>             addToResolveWorklist( f.getType(), SootClass.HIERARCHY );
>>>         }
>>>    ...
>>>
>>> As you can see here, this method iterates over all fields, which means
>>> that at this point it assumes all field signatures to already be
>>> present. In fact, the method does actually not do very much at all,
>>> except adding dependencies to the worklist. In particular, it does not
>>> really bring a class to signature level (except for changing the
>>> resolving level).
>>>
>>> Does anyone remember what was the intuition behind this?
>>>
>>> Cheers,
>>> Eric
>>> _______________________________________________
>>> 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



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt