|
Eran- Yes, we are currently struggling with this
as well. I asked Ondrej about it, and this was his reply: On
>
Hi Ondrej, >
>
Thanks for responding to our message re: Soot's call graph >
construction. >
>
>
If I understand you correctly there is no way to prevent Soot from > analyzing certain packages or sets of classes.
However, we don't want >
to spend processor time doing this analysis if we
don't have to. Our >
needs are much simpler -- we only want to analyze source/class files >
in our project (excluding all the .jars that this
project might use). >
>
For example, in the code below, we don't want Soot to waste time > analyzing JLabel or java.lang.String (or anything from java.*).
Our >
call graph can simply show that class Example invokes JLabel's >
constructor (and go no deeper than that). >
>
class Example{ >
>
JLabel
label; >
public
setText(String str){ >
label = new JLabel(str); >
} >
} >
>
Is this possible? >
>
Two reasons to avoid including the libraries that a java project might >
use: >
>
1) Speed (we don't care about these libraries, so we're only wasting >
processor time analyzing them) >
>
2) Memory (analyzing the libraries uses a tremendous amount of memory >
-- we'd prefer to avoid this if possible). >
>
If we cannot do this with Soot -- are you aware of any other java call > graph constructors out there that we should
look into? I
understand why you would want to do this. It is possible, but maybe not very
easy. A big challenge in the call graph code is to try to get the call graph as
complete as possible, so we didn't really design it for applications where you
want an intentionally incomplete call graph. So, you will have to tweak some of
the call graph construction code to get what you want, but it should be doable.
The call graph construction code is quite complicated, and I am often making
changes to it. However, the basic idea is this: start with a set of entry
points as reachable methods, then for each reachable method, process it with
the complicated code, looking for implicit and explicit calls, and add the
corresponding call edges. Then look at the destinations of the call edges for
more reachable methods, and repeat the process on those methods. The class ReachableMethods keeps track of and tells the rest of the
system which methods are considered reachable. So, I think the easiest solution
would be to modify this class to make only the methods you're interested in be
considered reachable. Hopefully, this will be the only change necessary, but it
may not. This is what I would try first. In
ReachableMethods.java, there is the method: private
void addMethod( MethodOrMethodContext
m ) {
if( set.add( m ) ) {
reachables.add( m );
} } I
would change this to something like this: private
void addMethod( MethodOrMethodContext
m ) {
if( set.add( m ) && methodIsWanted( m ) ) {
reachables.add( m );
} } where methodIsWanted() returns true if the method is not part of
the library. I'd
suggest you try this and see what kind of graph you get. If it gives you what
you want, great. If not, let me know and I'll try to suggest other things that
might need tweaking. Ondrej --------------------- jfroehli@ics.uci.edu CS Graduate Student,
UC-Irvine http://www.ics.uci.edu/~jfroehli -----Original Message----- Hi, Is there a standard way to filter-out the classes for
which the call-graph is constructed? I've seen some previous related correspondence in the list
in which Ondrej mentioned some solutions, are these available? It seems to me that the problem of call-graph construction
overhead (especially for small input programs) affects all Soot users, so a
standard common solution is desirable. Thanks, Eran |