Callable identification should be further up the analysis #207
Labels
Comments
khatchad
added
enhancement
khatchad
added a commit
to ponder-lab/ML
that referenced
this issue
Jul 19, 2024
In the past, we could add 0's to the parameters, but since we are not enforcing the existing of the node in the CG, we can no longer do that. Still, this test should now fail if wala#207 is fixed.
khatchad
added a commit
to ponder-lab/ML
that referenced
this issue
Jul 19, 2024
* Return `null` when there are multiple possible callables. * Add test to exercise call string imprecision. Based on the call string length. See wala/WALA#1417 (reply in thread). * Expect the test to fail. In the past, we could add 0's to the parameters, but since we are not enforcing the existing of the node in the CG, we can no longer do that. Still, this test should now fail if wala#207 is fixed.
khatchad
added a commit
to ponder-lab/ML
that referenced
this issue
Jul 21, 2024
* Return `null` when there are multiple possible callables. * Add test to exercise call string imprecision. Based on the call string length. See wala/WALA#1417 (reply in thread). * Expect the test to fail. In the past, we could add 0's to the parameters, but since we are not enforcing the existing of the node in the CG, we can no longer do that. Still, this test should now fail if wala#207 is fixed.
khatchad
added a commit
that referenced
this issue
Jul 26, 2024
* Return `null` when there are multiple possible callables. * Add test to exercise call string imprecision. Based on the call string length. See wala/WALA#1417 (reply in thread). * Expect the test to fail. In the past, we could add 0's to the parameters, but since we are not enforcing the existing of the node in the CG, we can no longer do that. Still, this test should now fail if #207 is fixed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Related to wala/WALA#1417 (reply in thread)
In the current callable identification code, we are seeing imprecision in identifing the callable when there's multiple possible receivers according to the PA. This could happen for a number of reasons (one test case is added in ponder-lab#121), but what we are seeing is that if the call stack is sufficiently deep, we lose the ability to distinguish objects in the PA. Another reason could be due to dynamic dispatch, though we haven't tested it yet.
The reason we are using PA in the first place is because the receiver comes to use as just an object with no other information. If we explicitly call
__call__(), the receiver is instead a trampoline. Thus, it would seem to me that calls to objects need to be distinguished before we get tocom.ibm.wala.ipa.callgraph.MethodTargetSelector.getCalleeTarget(). In other words, while this method works for a bunch of cases, I don't think it's the correct place to do it properly. Instead, we should figure out how to make the receiver the same as it was called explicitly.`The text was updated successfully, but these errors were encountered: