-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C++: Improve function pointer resolution #17788
C++: Improve function pointer resolution #17788
Conversation
cpp/ql/lib/change-notes/2024-10-16-new-api-for-call-target-resolution.md
Outdated
Show resolved
Hide resolved
* | ||
* Note that `call` may be a call to a function pointer expression. | ||
*/ | ||
Function getARuntimeTarget(Call call) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm always slightly confused. Is DataFlowUtil
the file whose contents users may still depend upon, although it's located in internal
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct:
import DataFlowUtil |
I don't know why this was done like this. This file structure is also present in the old AST dataflow, and we just copied it for IR dataflow.
We could actually change this, and maybe rename DataFlowUtil
to DataFlowPublic
to clear this confusion like it's been done for newer languages:
(although it looks like every language still stores the file in internal
for some reason 🤔)
…olution.md Co-authored-by: Jeroen Ketema <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This uses the existing "lambda resolution" mechanism in the dataflow library to resolve calls through function pointers.
We already track function addresses flowing into MaD models that specify a function pointer as an input (which was added in e9cd2dc). However, we never went the extra mile and added it when you call the function pointer in the source code.
This PR adds the one line which enables this. This should hopefully mean that we resolve a lot more function pointers.
Ideally, I would have liked to also remove the old function pointer resolution and virtual dispatch code, but since this is such a small change I think we should just get this improvement in now.
@bdrodes noted that he would also like for the call target resolution to be exposed as a predicate. I've snuck that into this PR in a99d576
All the results look like new genuine results with no performance problems in sight 🥳