- Removed the phasar-library
phasar_controller
. It is now part of the toolphasar-cli
. - The API of the
TypeHierarchy
interface (and thus theLLVMTypeHierarchy
andDIBasedTypeHierarchy
as well) has changed:- No handling of the super-type relation (only sub-types)
- No VTable handling anymore -- has been out-sourced into
LLVMVFTableProvider
- minor API changes
- The constructors of the call-graph resolvers have changed. They:
- take the
LLVMProjectIRDB
as pointer-to-const - take an additional second parameter of type
const LLVMVFTableProvider *
- not necessarily require a
LLVMTypeHierarchy
anymore
- take the
- Some constructors of
LLVMBasedICFG
do not accept aLLVMTypeHierarchy
pointer anymore - Removed IfdsFieldSensTaintAnalysis as it relies on LLVM's deprecated typed-pointers.
- Versioning scheme has been changed from
<month><year>
to<year><month>
- Default build mode is no longer
SHARED
butSTATIC
. To build in shared mode, use the cmake optionBUILD_SHARED_LIBS
which we don't recommend anymore. Consider usingPHASAR_BUILD_DYNLIB
instead to build one big libphasar.so. - Build type
DebugSan
has been removed in favor of a new CMake optionPHASAR_ENABLE_SANITIZERS
that not only works inDebug
mode.
EdgeFunctionPtrType
is no longer astd::shared_ptr
. InsteadEdgeFunction<l_t>
should be used directly.EdgeFunction
is now a value-type that encapsulates its memory management by itself.- Concrete
EdgeFunction
types no longer derive from any base-class. Instead they just need to implement the required API functions.EdgeFunction
implementations should me move-constructible and can be implicitly cast toEdgeFunction
. To verify that your type implements the edge function interface use theIsEdgeFunction
type trait. The API functions have been changed as follows:- All API functions of
EdgeFunction
must beconst
qualified. EdgeFunctionPtrType composeWith(EdgeFunctionPtrType SecondFunction)
andEdgeFunctionPtrType joinWith(EdgeFunctionPtrType OtherFunction)
have been changed tostatic EdgeFunction<l_t> compose(EdgeFunctionRef<T> This, const EdgeFunction<l_t>& SecondFunction)
andstatic EdgeFunction<l_t> join(EdgeFunctionRef<T> This, const EdgeFunction<l_t>& OtherFunction)
respectively. Here, theThis
parameter models the formershared_from_this()
.bool equal_to(EdgeFunctionPtrType Other)const
has been changed tobool operator==(const T &Other)const noexcept
, whereT
is your concrete edge function type.void print(llvm::raw_ostream &OS, bool IsForDebug)
has been changed tofriend llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const T& EF)
.
- All API functions of
EdgeFunction
is tagged with[[clang::trivial_abi]]
. Hence, you should not rely on any destruction order within a top-level statement that uses temporaryEdgeFunction
objects.EdgeFunctionSingletonFactory
has been removed. UseEdgeFunctionSingletonCache
instead.TaintConfig
has been renamed toLLVMTaintConfig
. For generic code you may want to use the LLVM-independentTaintConfigBase
CRTP interface instead.- Renamed
phasar/PhasarLLVM/DataFlowSolver/
to eitherphasar/DataFlow/
orphasar/PhasarLLVM/DataFlow/
depending on whether the components need LLVMCore. Analoguous changes inlib/
andunittests/
. An incomplete list of moved/renamed files:phasar/PhasarLLVM/DataFlowSolver/IfdsIde/Solver/*
=>phasar/DataFlow/IfdsIde/Solver/*
phasar/PhasarLLVM/DataFlowSolver/IfdsIde/IDETabulationProblem.h
=>phasar/DataFlow/IfdsIde/IDETabulationProblem.h
phasar/DB/LLVMProjectIRDB.h
=>phasar/PhasarLLVM/DB/LLVMProjectIRDB.h
- ...
- Renamed and split up some libraries:
phasar_phasarllvm_utils
=>phasar_llvm_utils
phasar_typehierarchy
=>phasar_llvm_typehierarchy
phasar_ifdside
=>phasar_llvm_ifdside
phasar_controlflow
has its LLVM dependent stuff moved tophasar_llvm_controlflow
phasar_db
has its LLVM dependent stuff moved tophasar_llvm_db
phasar_pointer
has its LLVM dependent stuff moved tophasar_llvm_pointer
- Renamed the phasar tool
phasar-llvm
tophasar-cli
LLVMPointsTo[.*]
has been renamed toLLVMAlias[.*]
- The ctor of
LLVMAliasSet
now takes theLLVMProjectIRDB
as pointer instead of a reference to better document that it may capture the IRDB by reference. - The
PointsToInfo
interface has been replaced by the CRTP interfaceAliasInfoBase
. Introduced two type-erased implementations of that interface:AliasInfo
andAliasInfoRef
. In most cases you should replacePointsToInfo *
andLLVMPointsToInfo *
byAliasInfoRef
, bzw.LLVMAliasInfoRef
. - Introduced a new interface
PointsToInfoBase
and type-erased implementationsPointstoInfo
andPointsToInfoRef
. Don't confuse them with the oldPointsToInfo
!!! (However, they have different APIs, so you should encounter compilation errors then)
- Removed virtual interfaces
CFG<N,F>
andICFG<N,F>
and replaced by CRTP interfacesCFGBase
andICFGBase
. Use the concrete typesLLVMBasedICFG
andLLVMBasedCFG
instead. In template code you can use the type traitsis_crtp_base_of_v
andis_icfg_v
to check for conformance to the interfaces. - The
LLVMBasedICFG
now takes the IRDB as pointer instead of a reference to better document that it may capture the IRDB by reference. - Renamed
ProjectIRDB
toLLVMProjectIRDB
and added a generic CRTP interfaceProjectIRDBBase
that does not depend on LLVM - Changed the API of
LLVMProjectIRDB
: The IRDB does no longer link multiple LLVM modules together, i.e. the ctor that reads a module from a file now takes a single filename instead of a vector. If you still want to link multiple LLVM modules together, use LLVM's Linker functionality instead.ProjecIRDB::getAllModules()
has been removed andProjectIRDB::getWPAModule()
has been renamed toLLVMProjectIRDB::getModule()
. - The
LLVMProjectIRDB
ctor that takes a raw-pointer tollvm::Module
does no longer preprocess the module (i.e. attaching metadata IDs to it). You can still explicitly use theValueAnnotationPass
to do so manually. - The type
WholeProgramAnalysis
has been removed. UseAnalysisController
instead. - The IFDS and IDE TabulationProblems no longer take all of
LLVMProjectIRDB*
,LLVMTypeHierarchy*
,LLVMPointsToInfo*
andLLVMBasedICFG*
as an argument. Instead, they only get what they need. - The
IFDSSolver
andIDESolver
now take an instance of theICFGBase
interface as additional argument to their ctor (because the analysis problems now not necessarily store a reference to it anymore). - The
IDETabulationProblem
is now a base class ofIFDSTabulationProblem
(and not vice versa as it was previously). In their ctors they only take the bare minimum of arguments: The IRDB, the entrypoints and optionally the special zero-value. If the zero-value is not passed in the ctor (as it was previously), it has to be set from within the client analysis' ctor. You may use the new functioninitializeZeroValue(d_t)
for this.