Including Primary Classes and Methods(with Bodies) is worth?

[popthink]

Currently, Plume doesn't generate method bodies, classes, method stubs of basic classes such as String, Integer, StringConcatFactory, etc.

Thus semantic of code got broken by the absence.

In another works, they makes some mock model for linking them.
(some link them if called method is external while propagation or reaching-def)

Could we figure it out how to handle them?

This could be related with #96

[DavidBakerEffendi]

Regarding the current state of how the data flow analysis works, all interprocedural calls are treated as tainted and the analysis overapproximates. Due to this, there isn't much reason (for now) to really include external bodies. The advantage is that whenever there is a code updated, one doesn't have to re-run the analysis on all the methods - only the new ones - since the analysis itself is intraprocedural and independent of other methods.

But you do raise a valid point and that this limits any future analysis too. In Soot any method where Soot cannot retrieve a body is called a phantom ref - so we can something around method stub and method body pass where we find out which external methods do have bodies and can generate them since Soot is usually able to generate bodies for JDK classes like Object, String, etc.

In the extractor there is a point where allMs is split by external methods where only the heads are built headsToBuild and internal methods where we build their bodies bodiesToBuild. There should be a subset of the methods in headsToBuild where Soot can actually retrieve their bodies. So far in the MethodStubPass, all external method bodies are made to be call-to-returns so this will also have to be adjusted.

[DavidBakerEffendi]

But like I said, as it stands, the analysis doesn't rely on the external method bodies so this can be seen as a low-priority issue or one not worth it until analysis does consider these or is reliant on CALL edges