[Soot-list] How to get signatures from a class that is at resolving level HIERARCHY
Hal Hildebrand
hal.hildebrand at gmail.com
Tue Sep 21 15:53:24 EDT 2010
I'm of course not sure of this statement, but isn't what I'm trying to do
perfectly reasonable? In essence, I'm trying to load a class that hasn't
been loaded, and bring it up to signature level. Clearly, other classes
have been loaded in the system via some mechanism which produces the same
result I need. What's confusing to me is why my particular use case should
fail. In particular, why Soot tries to load signature information when
bringing the class up to hierarchy. Given this is the code path that other
classes are brought into the system, I don't quite understand what is
different about this particular case that causes it to fail.
On Tue, Sep 21, 2010 at 8:26 AM, Hal Hildebrand <hal.hildebrand at gmail.com>wrote:
> Unfortunately, I do not know the set of these classes before invoking -
> i.e. these are determined during the transformation and can't be listed a
> priori.
>
> :(
>
> On Tue, Sep 21, 2010 at 1:29 AM, Eric Bodden <
> bodden at st.informatik.tu-darmstadt.de> wrote:
>
>> Hi again.
>>
>> I think the following should work. Insert the following call *before*
>> calling soot.Main.main(..):
>>
>> Scene.v().addBasicClass("B", SootClass.SIGNATURES);
>>
>> Then Soot should actually take care of the rest. The above call will
>> cause Soot to reolve B all the way to signatures when B is requested.
>>
>> 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 21 September 2010 05:39, Hal Hildebrand <hal.hildebrand at gmail.com>
>> wrote:
>> > 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
>> >>>>
>> >>
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20100921/5e8cef62/attachment.html
More information about the Soot-list
mailing list