[Soot-list] How to get signatures from a class that is at resolving level HIERARCHY
hal.hildebrand at gmail.com
Mon Sep 20 21:37:10 EDT 2010
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);
> 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.
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
More information about the Soot-list