Expose AbstractInterpretation.getAEInstance() to Python - #57
Merged
Merged
Conversation
The course-side Assignment-3 Python helper calls
pysvf.AbstractInterpretation.getAEInstance() to obtain the SVF abstract
interpreter singleton. Previously pysvf intentionally did NOT bind
getAEInstance because a straightforward .def_static hit a static_assert
deep inside <bits/stl_uninitialized.h>: pybind11 instantiates
make_(copy|move)_constructor<AbstractInterpretation> whenever a binding
returns the type, and AbstractInterpretation owns a
vector<unique_ptr<AEDetector>> that makes the implicit copy/move ctors
ill-formed, but the standard traits don't catch this until the body is
generated.
Two-part workaround:
1. pybind/AE.cpp:
- Specialise pybind11::detail::is_copy_constructible<T> and
is_move_constructible<T> for AbstractInterpretation, so pybind11
skips both factory paths when binding methods on the class.
- Add the py::nodelete holder so pybind never tries to delete the
SVF-owned singleton.
- Bind a module-level shim _AbstractInterpretation_getAEInstance
(the .def_static path turned out to take a different SFINAE route
that the trait specialisations don't cover).
2. pysvf/__init__.py: import the shim and attach it as
AbstractInterpretation.getAEInstance = staticmethod(...), so Python
callers use the natural class-method form.
3. pysvf/pysvf.pyi: add the @staticmethod stub entry.
Verified end-to-end in Docker against svftools/software-security-analysis
image (after applying the SVF leak-singleton fix to libSvfCore.so):
SSA Python Assignment-3 tests now reach the analysis logic instead of
crashing at import; ctest pass rate 28/64 -> 62/64.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The course-side Assignment-3 Python helper calls
pysvf.AbstractInterpretation.getAEInstance() to obtain the SVF abstract interpreter singleton. Previously pysvf intentionally did NOT bind getAEInstance because a straightforward .def_static hit a static_assert deep inside <bits/stl_uninitialized.h>: pybind11 instantiates make_(copy|move)_constructor whenever a binding returns the type, and AbstractInterpretation owns a vector<unique_ptr> that makes the implicit copy/move ctors ill-formed, but the standard traits don't catch this until the body is generated.
Two-part workaround:
pybind/AE.cpp:
pysvf/init.py: import the shim and attach it as AbstractInterpretation.getAEInstance = staticmethod(...), so Python callers use the natural class-method form.
pysvf/pysvf.pyi: add the @staticmethod stub entry.
Verified end-to-end in Docker against svftools/software-security-analysis image (after applying the SVF leak-singleton fix to libSvfCore.so): SSA Python Assignment-3 tests now reach the analysis logic instead of crashing at import; ctest pass rate 28/64 -> 62/64.