My name is Matan. I read your excellent Boomerang paper (over and over again..) after also watching the great DECA I/II course by prof. Bodden (and also reading the SPDS paper). I'm trying to reproduce this paper by re-implement Boomerang for Java in Golang.
I also looked at the code for the Java implementation of Boomerang by your group, but unfortunately I find it impenetrable. This is one of the reasons I want to re-implement it (understand it by building it)
I have a few open questions that I'm still not clear about and would greatly appreciate some clarification.
Is the client-driven context mechanism also used within subqueries?
for example, in figure 1. when performing a forward query starting from context1 at the allocation at line #4 asking which access paths at foo point to it; we encounter a field-write POI at a.f = s this should trigger an "AllAliases" query at this point which should only look at context1.
How is this information represented and passed to the subquery? Using the same mechanism described at "4.2 Client-Driven Context-Resolution"?
How can the idea about call/return POIs be implemented using SPDS instead of the access graph formulation (i.e. when we have a field-pds & automaton instead of an access graph)? In the access graph formulation we recursively query for all prefixes - How is this translated into the SPDS formulation?
Can dynamic fields and calls be supported as more POIs? by dynamic fields I mean x[f] where f is a variable (e.g. hashmaps or arrays), by dynamic calls I mean f(..) where f is variable (e.g. lambdas). My thought is that we can set the domain of fields to be all allocation sites and each statement involving dynamic fields as a POI which requires a PointsTo query to obtain the set of possible fields for this statement.
Hi Johannas! Hope you are doing well.
My name is Matan. I read your excellent Boomerang paper (over and over again..) after also watching the great DECA I/II course by prof. Bodden (and also reading the SPDS paper). I'm trying to reproduce this paper by re-implement Boomerang for Java in Golang. I also looked at the code for the Java implementation of Boomerang by your group, but unfortunately I find it impenetrable. This is one of the reasons I want to re-implement it (understand it by building it)
I have a few open questions that I'm still not clear about and would greatly appreciate some clarification.
for example, in figure 1. when performing a forward query starting from context1 at the allocation at line #4 asking which access paths at foo point to it; we encounter a field-write POI at
a.f = sthis should trigger an "AllAliases" query at this point which should only look at context1. How is this information represented and passed to the subquery? Using the same mechanism described at "4.2 Client-Driven Context-Resolution"?How can the idea about call/return POIs be implemented using SPDS instead of the access graph formulation (i.e. when we have a field-pds & automaton instead of an access graph)? In the access graph formulation we recursively query for all prefixes - How is this translated into the SPDS formulation?
Can dynamic fields and calls be supported as more POIs? by dynamic fields I mean
x[f]wherefis a variable (e.g. hashmaps or arrays), by dynamic calls I meanf(..)wherefis variable (e.g. lambdas). My thought is that we can set the domain of fields to be all allocation sites and each statement involving dynamic fields as a POI which requires a PointsTo query to obtain the set of possible fields for this statement.