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

[Hal Hildebrand]

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/af059932/attachment-0001.html