2008-02-16 09:12:31 +08:00
|
|
|
//== SymbolManager.h - Management of Symbolic Values ------------*- C++ -*--==//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2008-03-06 18:40:09 +08:00
|
|
|
// This file defines SymbolManager, a class that manages symbolic values
|
2008-02-16 09:12:31 +08:00
|
|
|
// created for use by GRExprEngine and related classes.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "clang/Analysis/PathSensitive/SymbolManager.h"
|
2008-12-20 14:32:12 +08:00
|
|
|
#include "clang/Analysis/PathSensitive/MemRegion.h"
|
2008-12-05 10:45:20 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2008-02-16 09:12:31 +08:00
|
|
|
|
|
|
|
using namespace clang;
|
|
|
|
|
2008-12-05 10:45:20 +08:00
|
|
|
void SymbolRef::print(llvm::raw_ostream& os) const {
|
|
|
|
os << getNumber();
|
|
|
|
}
|
|
|
|
|
Static analyzer: Remove a bunch of outdated SymbolData objects and
their associated APIs. We no longer need separate SymbolData objects
for fields, variables, etc. Instead, we now associated symbols with
the "rvalue" of a MemRegion (i.e., the value stored at that region).
Now we only have two kinds of SymbolData objects: SymbolRegionRValue
and SymbolConjured.
This cleanup also makes the distinction between a SymbolicRegion and a
symbolic value that is a location much clearer. A SymbolicRegion
represents a chunk of symbolic memory, while a symbolic location is
just a "pointer" with different possible values. Without any specific
knowledge, a symbolic location resolves (i.e., via a dereference) to a
SymbolicRegion. In the future, when we do better alias reasoning, a
symbolic location can become an alias for another location, thus
merging the constraints on the referred SymbolicRegion with the other
region.
llvm-svn: 62769
2009-01-23 02:23:34 +08:00
|
|
|
SymbolRef SymbolManager::getRegionRValueSymbol(const MemRegion* R) {
|
2008-03-12 09:21:45 +08:00
|
|
|
llvm::FoldingSetNodeID profile;
|
|
|
|
|
Static analyzer: Remove a bunch of outdated SymbolData objects and
their associated APIs. We no longer need separate SymbolData objects
for fields, variables, etc. Instead, we now associated symbols with
the "rvalue" of a MemRegion (i.e., the value stored at that region).
Now we only have two kinds of SymbolData objects: SymbolRegionRValue
and SymbolConjured.
This cleanup also makes the distinction between a SymbolicRegion and a
symbolic value that is a location much clearer. A SymbolicRegion
represents a chunk of symbolic memory, while a symbolic location is
just a "pointer" with different possible values. Without any specific
knowledge, a symbolic location resolves (i.e., via a dereference) to a
SymbolicRegion. In the future, when we do better alias reasoning, a
symbolic location can become an alias for another location, thus
merging the constraints on the referred SymbolicRegion with the other
region.
llvm-svn: 62769
2009-01-23 02:23:34 +08:00
|
|
|
SymbolRegionRValue::Profile(profile, R);
|
|
|
|
void* InsertPos;
|
|
|
|
SymbolData* SD = DataSet.FindNodeOrInsertPos(profile, InsertPos);
|
|
|
|
if (SD) return SD->getSymbol();
|
2008-02-16 09:12:31 +08:00
|
|
|
|
Static analyzer: Remove a bunch of outdated SymbolData objects and
their associated APIs. We no longer need separate SymbolData objects
for fields, variables, etc. Instead, we now associated symbols with
the "rvalue" of a MemRegion (i.e., the value stored at that region).
Now we only have two kinds of SymbolData objects: SymbolRegionRValue
and SymbolConjured.
This cleanup also makes the distinction between a SymbolicRegion and a
symbolic value that is a location much clearer. A SymbolicRegion
represents a chunk of symbolic memory, while a symbolic location is
just a "pointer" with different possible values. Without any specific
knowledge, a symbolic location resolves (i.e., via a dereference) to a
SymbolicRegion. In the future, when we do better alias reasoning, a
symbolic location can become an alias for another location, thus
merging the constraints on the referred SymbolicRegion with the other
region.
llvm-svn: 62769
2009-01-23 02:23:34 +08:00
|
|
|
SD = (SymbolData*) BPAlloc.Allocate<SymbolRegionRValue>();
|
|
|
|
new (SD) SymbolRegionRValue(SymbolCounter, R);
|
2008-03-12 09:21:45 +08:00
|
|
|
DataSet.InsertNode(SD, InsertPos);
|
Static analyzer: Remove a bunch of outdated SymbolData objects and
their associated APIs. We no longer need separate SymbolData objects
for fields, variables, etc. Instead, we now associated symbols with
the "rvalue" of a MemRegion (i.e., the value stored at that region).
Now we only have two kinds of SymbolData objects: SymbolRegionRValue
and SymbolConjured.
This cleanup also makes the distinction between a SymbolicRegion and a
symbolic value that is a location much clearer. A SymbolicRegion
represents a chunk of symbolic memory, while a symbolic location is
just a "pointer" with different possible values. Without any specific
knowledge, a symbolic location resolves (i.e., via a dereference) to a
SymbolicRegion. In the future, when we do better alias reasoning, a
symbolic location can become an alias for another location, thus
merging the constraints on the referred SymbolicRegion with the other
region.
llvm-svn: 62769
2009-01-23 02:23:34 +08:00
|
|
|
DataMap[SymbolCounter] = SD;
|
2008-11-19 19:03:17 +08:00
|
|
|
return SymbolCounter++;
|
|
|
|
|
|
|
|
}
|
2008-03-12 09:21:45 +08:00
|
|
|
|
Static analyzer: Remove a bunch of outdated SymbolData objects and
their associated APIs. We no longer need separate SymbolData objects
for fields, variables, etc. Instead, we now associated symbols with
the "rvalue" of a MemRegion (i.e., the value stored at that region).
Now we only have two kinds of SymbolData objects: SymbolRegionRValue
and SymbolConjured.
This cleanup also makes the distinction between a SymbolicRegion and a
symbolic value that is a location much clearer. A SymbolicRegion
represents a chunk of symbolic memory, while a symbolic location is
just a "pointer" with different possible values. Without any specific
knowledge, a symbolic location resolves (i.e., via a dereference) to a
SymbolicRegion. In the future, when we do better alias reasoning, a
symbolic location can become an alias for another location, thus
merging the constraints on the referred SymbolicRegion with the other
region.
llvm-svn: 62769
2009-01-23 02:23:34 +08:00
|
|
|
SymbolRef SymbolManager::getConjuredSymbol(Stmt* E, QualType T, unsigned Count){
|
2008-03-12 09:21:45 +08:00
|
|
|
|
|
|
|
llvm::FoldingSetNodeID profile;
|
2008-10-01 08:21:14 +08:00
|
|
|
SymbolConjured::Profile(profile, E, T, Count);
|
2008-03-12 09:21:45 +08:00
|
|
|
void* InsertPos;
|
|
|
|
|
|
|
|
SymbolData* SD = DataSet.FindNodeOrInsertPos(profile, InsertPos);
|
|
|
|
|
|
|
|
if (SD)
|
|
|
|
return SD->getSymbol();
|
|
|
|
|
2008-03-13 05:45:47 +08:00
|
|
|
SD = (SymbolData*) BPAlloc.Allocate<SymbolConjured>();
|
2008-10-01 08:21:14 +08:00
|
|
|
new (SD) SymbolConjured(SymbolCounter, E, T, Count);
|
2008-03-12 09:21:45 +08:00
|
|
|
|
|
|
|
DataSet.InsertNode(SD, InsertPos);
|
|
|
|
DataMap[SymbolCounter] = SD;
|
|
|
|
|
|
|
|
return SymbolCounter++;
|
|
|
|
}
|
|
|
|
|
2008-12-05 10:27:51 +08:00
|
|
|
const SymbolData& SymbolManager::getSymbolData(SymbolRef Sym) const {
|
2008-03-12 09:21:45 +08:00
|
|
|
DataMapTy::const_iterator I = DataMap.find(Sym);
|
|
|
|
assert (I != DataMap.end());
|
|
|
|
return *I->second;
|
|
|
|
}
|
|
|
|
|
2008-02-16 09:12:31 +08:00
|
|
|
|
Static analyzer: Remove a bunch of outdated SymbolData objects and
their associated APIs. We no longer need separate SymbolData objects
for fields, variables, etc. Instead, we now associated symbols with
the "rvalue" of a MemRegion (i.e., the value stored at that region).
Now we only have two kinds of SymbolData objects: SymbolRegionRValue
and SymbolConjured.
This cleanup also makes the distinction between a SymbolicRegion and a
symbolic value that is a location much clearer. A SymbolicRegion
represents a chunk of symbolic memory, while a symbolic location is
just a "pointer" with different possible values. Without any specific
knowledge, a symbolic location resolves (i.e., via a dereference) to a
SymbolicRegion. In the future, when we do better alias reasoning, a
symbolic location can become an alias for another location, thus
merging the constraints on the referred SymbolicRegion with the other
region.
llvm-svn: 62769
2009-01-23 02:23:34 +08:00
|
|
|
QualType SymbolConjured::getType(ASTContext&) const {
|
|
|
|
return T;
|
|
|
|
}
|
2008-12-05 09:31:31 +08:00
|
|
|
|
Static analyzer: Remove a bunch of outdated SymbolData objects and
their associated APIs. We no longer need separate SymbolData objects
for fields, variables, etc. Instead, we now associated symbols with
the "rvalue" of a MemRegion (i.e., the value stored at that region).
Now we only have two kinds of SymbolData objects: SymbolRegionRValue
and SymbolConjured.
This cleanup also makes the distinction between a SymbolicRegion and a
symbolic value that is a location much clearer. A SymbolicRegion
represents a chunk of symbolic memory, while a symbolic location is
just a "pointer" with different possible values. Without any specific
knowledge, a symbolic location resolves (i.e., via a dereference) to a
SymbolicRegion. In the future, when we do better alias reasoning, a
symbolic location can become an alias for another location, thus
merging the constraints on the referred SymbolicRegion with the other
region.
llvm-svn: 62769
2009-01-23 02:23:34 +08:00
|
|
|
QualType SymbolRegionRValue::getType(ASTContext& C) const {
|
|
|
|
if (const TypedRegion* TR = dyn_cast<TypedRegion>(R))
|
|
|
|
return TR->getRValueType(C);
|
|
|
|
|
|
|
|
return QualType();
|
2008-02-16 09:12:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
SymbolManager::~SymbolManager() {}
|
2009-01-22 06:26:05 +08:00
|
|
|
|
|
|
|
void SymbolReaper::markLive(SymbolRef sym) {
|
|
|
|
TheLiving = F.Add(TheLiving, sym);
|
|
|
|
TheDead = F.Remove(TheDead, sym);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SymbolReaper::maybeDead(SymbolRef sym) {
|
|
|
|
if (isLive(sym))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
TheDead = F.Add(TheDead, sym);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
Static analyzer: Remove a bunch of outdated SymbolData objects and
their associated APIs. We no longer need separate SymbolData objects
for fields, variables, etc. Instead, we now associated symbols with
the "rvalue" of a MemRegion (i.e., the value stored at that region).
Now we only have two kinds of SymbolData objects: SymbolRegionRValue
and SymbolConjured.
This cleanup also makes the distinction between a SymbolicRegion and a
symbolic value that is a location much clearer. A SymbolicRegion
represents a chunk of symbolic memory, while a symbolic location is
just a "pointer" with different possible values. Without any specific
knowledge, a symbolic location resolves (i.e., via a dereference) to a
SymbolicRegion. In the future, when we do better alias reasoning, a
symbolic location can become an alias for another location, thus
merging the constraints on the referred SymbolicRegion with the other
region.
llvm-svn: 62769
2009-01-23 02:23:34 +08:00
|
|
|
bool SymbolReaper::isLive(SymbolRef sym) {
|
2009-01-23 02:51:33 +08:00
|
|
|
if (TheLiving.contains(sym))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Interogate the symbol. It may derive from an input value to
|
|
|
|
// the analyzed function/method.
|
|
|
|
return isa<SymbolRegionRValue>(SymMgr.getSymbolData(sym));
|
2009-01-22 06:26:05 +08:00
|
|
|
}
|
2009-02-14 11:16:10 +08:00
|
|
|
|
|
|
|
SymbolVisitor::~SymbolVisitor() {}
|