[Soot-list] Help (fwd)
Philippe Laporte
philippel at bluestreaktech.com
Fri May 18 15:30:19 EDT 2007
Hi,
I've just used SOOT to process my J2ME-CLDC app.
After doing the soot.G and soot.toolkits.exceptions.ThrowableSet changes
all ran fine.
The total size has increased, and I have not been yet able to measure
any performance improvements.
The arguments I am using are:
-O -W -soot-class-path <wtk libs + jsrs>;<classes to process root dir>
-process-dir <classes to process root dir> -output-dir <classes to
process root dir>
--app -p wjop.smb on -p wjop.si off <midlet class>
Can we expect a size increase with all speed increases (inlining?), or
is there a switch or command-line options to only enable size-reducing
optimizations?
As a side note I am wondering if there was not any J2ME-CLDC
feedback/eager use in the mean-time since the
soot.toolkits.exceptions.ThrowableSet problem is still there. I think
the J2ME-CLDC community should be most enthusiastic about using SOOT in
a SOOT | obfuscator pipeline.
Thanks a lot,
Philippe Laporte
Senior Software Developer
Bluestreak Technology, Inc.
philippel at bluestreaktech.com <mailto:mphilippel at bluestreaktech.com>
-----Original Message-----
Stephen Cheng scheng at innaworks.com
<mailto:soot-list%40cs.mcgill.ca?Subject=%5BSoot-list%5D%20Help%20%28fwd
%29&In-Reply-To=Pine.GS4.4.58.0505252248100.20459%40kohinoor.csa.iisc.er
net.in>
Sun May 29 17:28:02 EDT 2005
Hello Rahul and Ondrej,
Ondrej mentioned a J2ME patch I submitted some time ago. We were working
on
a prototype of mBooster (http://www.innaworks.com), the first commercial
J2ME optimizing compiler, using Soot. Eventually for robustness and cost
effectiveness we decided to build our own proprietary framework
from-the-ground-up, due to our special requirements and various J2ME and
other issues we encountered with Soot
Here is a partial list of issues it you may need to look at to make Soot
work with J2ME:
1. Array type interfaces are different with J2ME CLDC
2. The side effect models are currently based on J2SE 1.3, and
"incompatible" for J2ME CLDC.
In short the patch I submitted is only a small part of the solution
required
to make Soot work with J2ME. From memory it partially addresses issue 1.
To
realistically make Soot work with J2ME in a robust manner, significant
rework/investment should be expected.
Regards,
Stephen
-----Original Message-----
From: soot-list-bounces at cs.mcgill.ca
<http://www.sable.mcgill.ca/mailman/listinfo/soot-list>
[mailto:soot-list-bounces at cs.mcgill.ca
<http://www.sable.mcgill.ca/mailman/listinfo/soot-list> ]
On Behalf Of Rahul Nagpal
Sent: Thursday, 26 May 2005 6:03 a.m.
To: Ondrej Lhotak
Cc: soot-list at sable.mcgill.ca
<http://www.sable.mcgill.ca/mailman/listinfo/soot-list>
Subject: Re: [Soot-list] Help (fwd)
Hi Ondroz,
Thanks for pointing out that. Though I set the flag to true and
recompiled the G.java file containing the flag. I did not recompiled the
javafiles that uses the flag. After doing that change I got the error[1]
that I could get rid of by commenting out these two lines (Thought I
don't
know what can be the possible sideeffect of doing this)
239:resolveClassErrorSet.add(AnySubType.v(Scene.v().getRefType("java.lan
g.Cl
assFormatError")));
263:initializationErrorSet.add(AnySubType.v(Scene.v().getRefType("java.l
ang.
Error")));
in file "soot/toolkits/exceptions/ThrowableSet.java". Now I am
successful
in using soot directly with the J2ME library along with -w
flag to create the callgraph for HelloWorld Program at least.
I am also able to use the ptolemy interfaced with
soot if I bypass the callgraph creation. However if I create the
callgraph
from ptolemy which creats the call graph with some specific options and
some default starting points I get one of the old error[2]. I am looking
at the matter at present. I am attaching a java source file from
ptolemy
that call the soot functions for creating the call graph.
I will be thankful if you can give me some hint on what might be
the cause of this problem.
Thanks a lot
Rahul
[1]Exception in thread "main" java.lang.NullPointerException
at soot.AnySubType.v(AnySubType.java:44)
at
soot.toolkits.exceptions.ThrowableSet$Manager.<init>(ThrowableSet.java:2
63)
at
soot.Singletons.soot_toolkits_exceptions_ThrowableSet_Manager(Singletons
.jav
a:1005)
at
soot.toolkits.exceptions.ThrowableSet$Manager.v(ThrowableSet.java:274)
at
soot.toolkits.exceptions.PedanticThrowAnalysis.mightThrow(PedanticThrowA
naly
sis.java:68)
at
soot.toolkits.graph.ExceptionalUnitGraph.getExceptionDests(ExceptionalUn
itGr
aph.java:803)
at
soot.toolkits.graph.ExceptionalUnitGraph.buildHeadsAndTails(ExceptionalU
nitG
raph.java:766)
at
soot.toolkits.graph.ExceptionalUnitGraph.initialize(ExceptionalUnitGraph
.jav
a:283)
at
soot.toolkits.graph.ExceptionalUnitGraph.<init>(ExceptionalUnitGraph.jav
a:14
8)
at
soot.toolkits.graph.ExceptionalUnitGraph.<init>(ExceptionalUnitGraph.jav
a:18
0)
at
soot.toolkits.scalar.LocalSplitter.internalTransform(LocalSplitter.java:
78)
at soot.BodyTransformer.transform(BodyTransformer.java:51)
at soot.Transform.apply(Transform.java:104)
at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:61)
at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:93)
at soot.Pack.apply(Pack.java:120)
at
soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:115)
at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:80)
at soot.SootMethod.retrieveActiveBody(SootMethod.java:304)
at
ptolemy.copernicus.c.MethodCodeGenerator.generate(MethodCodeGenerator.ja
va:7
6)
at
ptolemy.copernicus.c.CodeFileGenerator.generate(CodeFileGenerator.java:1
46)
at
ptolemy.copernicus.c.RequiredFileGenerator._generateC(RequiredFileGenera
tor.
java:282)
at
ptolemy.copernicus.c.RequiredFileGenerator.generateTransitiveClosureOf(R
equi
redFileGenerator.java:94)
at ptolemy.copernicus.c.JavaToC.convert(JavaToC.java:119)
at ptolemy.copernicus.c.JavaToC.main(JavaToC.java:186)
[2]
Exception in thread "main"
soot.AbstractSootMethodRef$ClassResolutionFailedException: Class
com.sun.cldc.io.ConsoleOutputStream doesn't have method <init>([]) :
void;
failed to resolve in superclasses and interfacesLooking in
com.sun.cldc.io.ConsoleOutputStream which has methods []
at
soot.AbstractSootMethodRef.resolve(AbstractSootMethodRef.java:136)
at
soot.AbstractSootMethodRef.resolve(AbstractSootMethodRef.java:95)
at
soot.jimple.internal.AbstractInvokeExpr.getMethod(AbstractInvokeExpr.jav
a:55
)
at
soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.getImplicitTargets(
OnFl
yCallGraphBuilder.java:235)
at
soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processNewMethod(On
FlyC
allGraphBuilder.java:183)
at
soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processReachables(O
nFly
CallGraphBuilder.java:81)
at
soot.jimple.spark.solver.OnFlyCallGraph.build(OnFlyCallGraph.java:69)
at
soot.jimple.spark.builder.ContextInsensitiveBuilder.build(ContextInsensi
tive
Builder.java:78)
at
soot.jimple.spark.SparkTransformer.internalTransform(SparkTransformer.ja
va:5
3)
at soot.SceneTransformer.transform(SceneTransformer.java:39)
at
ptolemy.copernicus.c.CallGraphPruner.<init>(CallGraphPruner.java:109)
at
ptolemy.copernicus.c.RequiredFileGenerator._pruneLevel1(RequiredFileGene
rato
r.java:243)
at
ptolemy.copernicus.c.RequiredFileGenerator.init(RequiredFileGenerator.ja
va:1
52)
at ptolemy.copernicus.c.JavaToC.convert(JavaToC.java:89)
at ptolemy.copernicus.c.JavaToC.main(JavaToC.java:186)
On Tue, 24 May
2005, Ondrej Lhotak wrote:
-->On Tue, May 24, 2005 at 12:39:53AM +0530, Rahul Nagpal wrote:
-->> Hi,
-->> I hope you have received my last mail (in case not the details
are
-->> given below) where I have given the exception raised by soot if I
use
-->> j2me class directly with soot.
-->
-->Our whole lab was down for the past several days for hardware
upgrades.
-->Everything seems to be back now, and hopefully people are receiving
your
-->message.
-->
-->> I will be thankful if you can help (or redirect) me in this
-->> regard. I am ready to make whatever modification are required to
get
the
-->> soot working with j2me ( I will myself takeup the ptolmy inteface
part
later once I get
-->> the soot working with j2me classes). But because of my inexperience
with
-->> soot I am not able to find the cause of these problems.
-->
-->J2ME has somewhat different semantics than J2SE, and Soot is built
with
-->J2SE in mind. So, getting it to work with J2ME may require some
-->tinkering. Unfortunately, I don't know of anyone with experience
getting
-->Soot to work with J2ME that I could direct you to.
-->
-->I've walked through your stack trace for you, and noticed the
following
-->line:
-->at
soot.jimple.toolkits.typing.ClassHierarchy.<init>(ClassHierarchy.java:82
)
-->
-->The code at this point is:
--> 79 // hack for J2ME library which does not have Cloneable
and
Serializable
--> 80 // reported by Stephen Chen
--> 81 if (!G.v().isJ2ME) {
--> 82 CLONEABLE = typeNode(RefType.v("java.lang.Cloneable"));
--> 83 SERIALIZABLE =
typeNode(RefType.v("java.io.Serializable"));
--> 84 } else {
--> 85 CLONEABLE = null;
--> 86 SERIALIZABLE = null;
--> 87 }
-->
-->If you have isJ2ME set to true, line 82 (and 83) should never be
getting
-->executed.
-->
-->Ondrej
-->
-->>
-->> Thanks and Regards
-->> Rahul
-->>
-->> On Thu, 19 May 2005, Rahul Nagpal wrote:
-->>
-->> -->Hi,
-->> --> I think you are right. I should have first checked on the
-->> -->application directly. Now I have done that I got this error[1]
-->> -->if I use J2ME classes ( I am doing "java soot.Main -cp <the
j2me
class path>)
-->> -->irrespective of whether I use -w option or not.
-->> -->
-->> --> Notably the ptolemy is working fine with soot when I use
the
-->> -->J2SE classes and only the use of J2ME classes causes the
problem.
-->> -->
-->> -->Thanks and Regards
-->> -->Rahul
-->> -->
-->> -->[1]
-->> -->Exception in thread "main" java.lang.RuntimeException: This
operation
-->> -->requires resolving level HIERARCHY but java.lang.Cloneable is at
resolving
-->> -->level DANGLING
-->> --> at soot.SootClass.checkLevel(SootClass.java:123)
-->> --> at soot.SootClass.hasSuperclass(SootClass.java:702)
-->> --> at
soot.jimple.toolkits.typing.TypeNode.<init>(TypeNode.java:86)
-->> --> at
soot.jimple.toolkits.typing.ClassHierarchy$ConstructorChooser.caseRefTyp
e(Cl
assHierarchy.java:238)
-->> --> at soot.RefType.apply(RefType.java:137)
-->> --> at
soot.jimple.toolkits.typing.ClassHierarchy$ConstructorChooser.typeNode(C
lass
Hierarchy.java:231)
-->> --> at
soot.jimple.toolkits.typing.ClassHierarchy.typeNode(ClassHierarchy.java:
127)
-->> --> at
soot.jimple.toolkits.typing.ClassHierarchy.classHierarchy(ClassHierarchy
.jav
a:105)
-->> --> at
soot.jimple.toolkits.typing.TypeResolver.<init>(TypeResolver.java:153)
-->> --> at
soot.jimple.toolkits.typing.TypeResolver.resolve(TypeResolver.java:178)
-->> --> at
soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.
java
:57)
-->> --> at
soot.BodyTransformer.transform(BodyTransformer.java:51)
-->> --> at soot.Transform.apply(Transform.java:104)
-->> --> at
soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:70)
-->> --> at
soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:93)
-->> --> at soot.Pack.apply(Pack.java:120)
-->> --> at
soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:115)
-->> --> at
soot.SootMethod.getBodyFromMethodSource(SootMethod.java:80)
-->> --> at
soot.SootMethod.retrieveActiveBody(SootMethod.java:304)
-->> --> at
soot.PackManager.retrieveAllBodies(PackManager.java:711)
-->> --> at soot.PackManager.runPacks(PackManager.java:302)
-->> --> at soot.Main.run(Main.java:179)
-->> --> at soot.Main.main(Main.java:153)
-->> -->
-->> -->
-->> -->On Wed, 18 May 2005, Ondrej Lhotak wrote:
-->> -->
-->> -->-->On Tue, May 17, 2005 at 01:56:33AM +0530, Rahul Nagpal wrote:
-->> -->-->> [1]
-->> -->-->> Exception in thread "main"
-->> -->-->> soot.AbstractSootMethodRef$ClassResolutionFailedException:
Class
-->> -->-->> com.sun.cldc.io.ConsoleOutputStream doesn't have method
<init>([]) : void;
-->> -->-->> failed to resolve in superclasses and interfacesLooking in
-->> -->-->> com.sun.cldc.io.ConsoleOutputStream which has methods []
-->> -->-->> at
soot.AbstractSootMethodRef.resolve(AbstractSootMethodRef.java:136)
-->> -->-->
-->> -->-->....
-->> -->-->
-->> -->-->> at
ptolemy.copernicus.c.CallGraphPruner.<init>(CallGraphPruner.java:109)
-->> -->-->> at
ptolemy.copernicus.c.RequiredFileGenerator._pruneLevel1(RequiredFileGene
rato
r.java:243)
-->> -->-->> at
ptolemy.copernicus.c.RequiredFileGenerator.init(RequiredFileGenerator.ja
va:1
52)
-->> -->-->> at
ptolemy.copernicus.c.JavaToC.convert(JavaToC.java:89)
-->> -->-->> at
ptolemy.copernicus.c.JavaToC.main(JavaToC.java:186)
-->> -->-->
-->> -->-->Soot doesn't seem to have any methods in the class
-->> -->-->com.sun.cldc.io.ConsoleOutputStream, which suggests that the
class was
-->> -->-->not resolved properly. It could be due to some interaction
between
-->> -->-->Ptolemy and the Soot resolver. Does the same thing happen
when
you run
-->> -->-->Soot on your application, with the -w switch (to make it
build a
call
-->> -->-->graph)?
-->> -->-->
-->> -->-->> [2]Exception in thread "main"
java.lang.NullPointerException
-->> -->-->> at soot.AnySubType.v(AnySubType.java:44)
-->> -->-->> at
soot.toolkits.exceptions.ThrowableSet$Manager.<init>(ThrowableSet.java:2
39)
-->> -->-->> at
soot.Singletons.soot_toolkits_exceptions_ThrowableSet_Manager(Singletons
.jav
a:1005)
-->> -->-->> at
soot.toolkits.exceptions.ThrowableSet$Manager.v(ThrowableSet.java:274)
-->> -->-->
-->> -->-->...
-->> -->-->
-->> -->-->> at
ptolemy.copernicus.c.MethodCodeGenerator.generate(MethodCodeGenerator.ja
va:7
6)
-->> -->-->> at
ptolemy.copernicus.c.CodeFileGenerator.generate(CodeFileGenerator.java:1
46)
-->> -->-->> at
ptolemy.copernicus.c.RequiredFileGenerator._generateC(RequiredFileGenera
tor.
java:282)
-->> -->-->> at
ptolemy.copernicus.c.RequiredFileGenerator.generateTransitiveClosureOf(R
equi
redFileGenerator.java:94)
-->> -->-->> at
ptolemy.copernicus.c.JavaToC.convert(JavaToC.java:119)
-->> -->-->> at
ptolemy.copernicus.c.JavaToC.main(JavaToC.java:186)
-->> -->-->
-->> -->-->This suggests that the java.lang.ClassFormatError class is
not
getting
-->> -->-->loaded, even though the Scene sets it to be a basic class.
Maybe
Ptolemy
-->> -->-->is not running Scene.v().loadBasicClasses(). Again, does this
problem
-->> -->-->happen when you run Soot on your application?
-->> -->-->
-->> -->-->Ondrej
-->> -->-->
-->> -->-->
-->> -->
-->>
-->---------------------------------------------------------------------
-->> --> __ __
-->> --> / /\ / /\ RAHUL NAGPAL
-->> --> / /_/_/ / / Room No. U-77, IISc Hostels,
-->> --> /_______/ / /\
-->> --> \ ____ \ \/ \ Phone Nos 080-2293-2634/2591 (Hostel)
-->> --> \ \/__\ \ /\ \ 080-22932368/468-104 (Compiler Lab)
-->> --> \_______\/ / / 080-22932368-115 (CL1)
-->> --> /_/ / /_/ / 080-22932368-102 (CL2)
-->> --> \_\/ \_\/ 080-22932368-227 (Intel LAB)
-->>
-->--------------------------------------------------------------------
-->> -->
-->>
-->>
---------------------------------------------------------------------
-->> __ __
-->> / /\ / /\ RAHUL NAGPAL
-->> / /_/_/ / / Room No. U-77, IISc Hostels,
-->> /_______/ / /\
-->> \ ____ \ \/ \ Phone Nos 080-2293-2634/2591 (Hostel)
-->> \ \/__\ \ /\ \ 080-22932368/468-104 (Compiler Lab)
-->> \_______\/ / / 080-22932368-115 (CL1)
-->> /_/ / /_/ / 080-22932368-102 (CL2)
-->> \_\/ \_\/ 080-22932368-227 (Intel LAB)
-->>
--------------------------------------------------------------------
-->>
-->
---------------------------------------------------------------------
__ __
/ /\ / /\ RAHUL NAGPAL
/ /_/_/ / / Room No. U-77, IISc Hostels,
/_______/ / /\
\ ____ \ \/ \ Phone Nos 080-2293-2634/2591 (Hostel)
\ \/__\ \ /\ \ 080-22932368/468-104 (Compiler Lab)
\_______\/ / / 080-22932368-115 (CL1)
/_/ / /_/ / 080-22932368-102 (CL2)
\_\/ \_\/ 080-22932368-227 (Intel LAB)
--------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20070518/ccb0f094/attachment-0001.htm
More information about the Soot-list
mailing list