Description

Relates to #130

Currently, to use Boomerang with SootUp, you must create a SootUpFrameworkScope, which takes in a SootUp-initialized call graph and then constructs its own boomerang.scope.sootup.SootUpCallGraph.

However, during the construction of SootUpCallGraph, the code attempts to resolve static fields through the following call stack:

getSootField:187, SootUpFrameworkScope (boomerang.scope.sootup)
getStaticField:292, JimpleUpStatement (boomerang.scope.sootup.jimple)
computeStaticFieldsLoadAndStores:128, CallGraph (boomerang.scope)
addEntryPoint:103, CallGraph (boomerang.scope)
<init>:66, SootUpCallGraph (boomerang.scope.sootup)
<init>:59, SootUpFrameworkScope (boomerang.scope.sootup)

This process reaches the getSootField method, which tries to resolve the field from the view, disregarding whether the field should be accessible or not. As a result, phantom fields (i.e., unresolved fields from missing dependencies) cause runtime exceptions.

SootUp vs. Soot Behavior

Unlike Soot, which includes both application and library code by default, SootUp only includes application code unless explicitly configured otherwise. This means that unless the user manually includes the entire dependency set (e.g., JDK and all libraries), SootUp will treat any unresolved fields as phantom fields, potentially causing crashes.

Problem

To bypass this issue, one must include the entire codebases of all library dependencies (including the entire JDK) in the SootUp view. However, this conflicts with Boomerang’s default behavior during later analyses:

• While using Boomerang to generate seeds for subsequent analyses, the boomerang.scope.AnalysisScope::computeSeeds() method checks for phantom fields.
• If library analysis is not enabled, it ignores invocation statements referencing such fields.

Key Question

Why is full dependency inclusion required at call graph construction if those dependencies will later be ignored by default?

Expected Behavior

• Either SootUpCallGraph should handle phantom fields in a way that aligns with Boomerang’s later analysis behavior.
• Or there should be a way to construct the call graph without requiring full dependency inclusion when those dependencies are not being analyzed later.

Possible Solution Ideas

• Modify SootUpCallGraph to check for phantom fields before attempting resolution.

Would love to hear thoughts on this! Is this behavior intentional, or could it be improved?