[Soot-list] SootResolver.bringToX...

[Eric Bodden]

Thanks Patrick.

It seems that I misunderstood a bit the purpose of those methods (and
the different resolving levels). Apparently they are just about the
dependencies.

Cheers,
Eric

On 7 December 2011 18:50, Patrick Lam <plam at sable.mcgill.ca> wrote:
> On 12/07/2011 01:05 AM, 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?
>
> I don't really remember who rewrote the SootResolver, but it wasn't me.
>
> I do remember some exposure to this code thouogh. I think that there's a
> surprising amount of work that gets done while the Jimple is being
> created (e.g. by Coffi).
>
> Whenever Coffi loads a class, it will create the SootFields etc for that
> class. (See soot.coffi.util.resolveFromClassFile).
>
> It looks to me like whenever Soot loads a class to the SIGNATURES level,
> then the classes for the types of fields of that class will exist. Look
> at the doc comment for the bringToSignatures method: to me, it says that
> the signatures already exist.
>
> My guess, then, is as follows:
>
> If class c is at level:
> HIERARCHIES: there exists a SootClass for c
> SIGNATURES: ... and all of the types for the fields of c also exist
> BODIES: ... and the bodies also exist (I can no longer recall where they
> get created, but it's somewhere else.)
>
> pat
> _______________________________________________
> 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