[Soot-list] How to get signatures from a class that is at resolving level HIERARCHY

[Hal Hildebrand]

Okay, looking into this some more I find myself a bit confused as to what's exactly happening.  I've appended the stack trace below for context.

The class I'm trying to load hasn't been brought in and resolved, which I had mistakenly assumed was the case.  From my tracing of the logic, things seem to get out of whack because in SootResolver.bringToHierarchy() (line 183), the resolve level is set to HIERARCHY, regardless of what the desired level is - in this case SIGNATURES.  The problem with this is that SootClass.addField() requires the resolveLevel to be >= Signatures, and thus the raised RunTimeException.

I'm unclear of the logic here, as if any class that is being resolved to signatures would seem to have gone through this chain, but for this particular use case it's failing.  My naive thought would be that the bringToHierarchy should be checking that the level is >= HIERARCHY and setting it if it's not, but given that the existing logic works in all but this particular case I'm loathe to tug on that for fear of unravelling other threads.

Thread [main] (Suspended (exception RuntimeException))	
	SootClass.checkLevel(int) line: 121	
	SootClass.addField(SootField) line: 177	
	Util.resolveFromClassFile(SootClass, InputStream, List) line: 147	
	CoffiClassSource.resolve(SootClass) line: 39	
	SootResolver.bringToHierarchy(SootClass) line: 215	
	SootResolver.bringToSignatures(SootClass) line: 239	
	SootResolver.bringToBodies(SootClass) line: 280	
	SootResolver.processResolveWorklist() line: 150	
	SootResolver.resolveClass(String, int) line: 124	
	EntityConstructionTransformer.transform(NewExpr, Unit, PatchingChain<Unit>) line: 68	
	EntityConstructionTransformer.internalTransform(Body, String, Map) line: 110	
	EntityConstructionTransformer(BodyTransformer).transform(Body, String, Map) line: 51	
	Transform.apply(Body) line: 104	
	BodyPack.internalApply(Body) line: 49	
	BodyPack(Pack).apply(Body) line: 124	
	PackManager.runBodyPacks(SootClass) line: 784	
	PackManager.runBodyPacks(Iterator) line: 463	
	PackManager.runBodyPacks() line: 380	
	PackManager.runPacks() line: 357	
	Main.run(String[]) line: 198	
	Main.main(String[]) line: 141	
	SimulationTransform.main(String[]) line: 88	
	TestMe.main(String[]) line: 24	


On Sep 20, 2010, at 6:37 PM, Hal Hildebrand wrote:

> Unfortunately, that leads to the same fail:
> 
> Exception in thread "main" java.lang.RuntimeException: 
> 	This operation requires resolving level SIGNATURES but testClasses.DriverImpl$entity is at resolving level HIERARCHY
> If you are extending Soot, try to add the following call before calling soot.Main.main(..):
> 
> On Sep 19, 2010, at 11:30 PM, Eric Bodden wrote:
> 
>> Hal, the following method could work:
>> 
>> soot.SootResolver.v().resolveClass("B", SootClass.SIGNATURES);
>> 
>> Eric
>> 
>> --
>> Dr. Eric Bodden
>> Software Technology Group, Technische Universität Darmstadt, Germany
>> Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
>> Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt
>> 
>> 
>> 
>> On 20 September 2010 05:55, Hal Hildebrand <hal.hildebrand at gmail.com> wrote:
>>> So, I seem to be back in the weeds again.  Not sure if there's a way out, but I thought I'd ask the list for suggestions.
>>> 
>>> I'm using the set_no_bodies_for_excluded option, and all that implies.  The setup is that I have three classes, A, B and C.  A and B are on the soot class path, and are excluded.  C is being processed, and in the body of a method of C I am transforming a method invocation on A to B.  I have the method reference to the method on A, and although the method is declared on B, I cannot retrieve the method reference because B is pinned at resolving level HIERARCHY.
>>> 
>>> I believe I understand why this is happening, given that I do not reference B and thus the class is without method signatures.  What I am wondering  is whether there is some clever way around this trap I've set for myself.  The reason I'm using the set_no_bodies_for_excluded is because I cannot transform any method outside of the processing set and things get ugly pretty fast if I don't use that option.  Hopefully there's a way out of this, though.
>>> 
>>> Thanks,
>>> 
>>> -Hal
>>> _______________________________________________
>>> Soot-list mailing list
>>> Soot-list at sable.mcgill.ca
>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>> 
>