-
Notifications
You must be signed in to change notification settings - Fork 34
Description
Currently, the TAC reference.conf defines how certain native (or just relevant JDK) methods behave by lisiting a set of method invocations and also a set of entity assignments. The latter includes field writes, parameter assignments, method invocations and type instantiations, which can be assigned to each other to model the general behavior of such methods. Many different methods in our callgraph- and points-to analyses consume those configurations to model call edges, instantiated types and points-to behavior of those methods for which implementations are usually not available or for which reachability is hard to determine (e.g. because of reflection).
There are several issues with this system:
- Our configuration "language" is not very expressive. For example, it is not possible to model that one instance of a type is created and passed to two different method invocations.
- The configuration language is redundant - to express that a method may return a new type instantiation, we need to name the method's CF, name and descriptor a total of three times. We also have duplicated information about certain method invocations, which are modeled separately and in the entity assignments.
- Reading the configuration creates inconsistencies - the call graph analysis for example assigns the invocation PC 0 to all configured method invocations. However, the points-to analysis will create artificial (negative) PCs when processing the entity assignments, leading to points-to information PCs not necessarily aligning with invocation PCs
We want to improve on this by creating a new language for configuring the behavior of methods. It could be a form of "reduced TAC", where we are only interested in certain types of statements and expressions. One exciting idea would be to consume those configurations, create an "artificial" TAC for those configured methods and feed them into OPAL as (relatively) normal defined methods that can be processed by many analyses that work on TAC.
This issue came up during our discussion on this PR