In some cases the uses of a function are not `CallInst`s (e.g.
`ptrtoint`). Since DLA is only concerned with calls, ignore all the
other uses by using the `callers` functions.
The current implementation DLA cannot reason about function pointers,
because function types have zero size.
Given this shortcoming, llvm::Functions are used (as a hack) to
represent their Functions' return types.
This representation is a key factor of how DLA is able to piece
information together interprocedurally.
This hack has consequences.
Assume we're setting up the DLA graph, and we're looking at a use of an
llvm::Function that is inside the body of an llvm::Function and is not
the callee-operand of a Call.
That use is obviously function-pointer typed.
But if we try to create a LayoutTypeSystemNode for the llvm::Value of
the used llvm::Function, the inner machinery of how the DLA graph is
set up will treat is as the return type of the function, which is
obviously wrong.
So we have to prevent that creation at all costs.
Basically creation of LayoutTypeSystemNodes in the DLA graph associated
with llvm::Functions are valid only for representing return types.
This shortcoming does not affect the power of DLA. In its current form,
it doesn't represent function types at all.
The problem is that until we undo this hack we will not be able to
properly support function types in DLA.
This will have to be fixed in the future.
In the meantime, this commit provides an helper function to centralize
how we detect the offending uses of llvm::Functions. In this way, all
the points of the codebase that are affected by this hack are clearly
marked.
* Make the following private headers public:
* Lift/CPUStateAccessAnalysisPass.h
* Lift/CSVOffsets.h
* Lift/PTCDump.h
* Lift/VariableManager.h
* Move from revngSupport to revngLift:
* IRAnnotators.{h,cpp}
* SelfReferencingDbgAnnotationWriter.{h,cpp}
* Move from revngSupport to revngModel:
* FunctionTags.{h,cpp}
* ProgramCounterHandler.{h,cpp}
* Move from revngSupport to revngRecompile:
* OriginalAssemblyAnnotationWriter.{h,cpp}
Before this commit, the DLA frontend wasn't initializing the size of
stack types properly, nor tracking the fact that they are not scalar.
These 2 problems were causing stack types to be merged with other types
in the DLA pipeline, possibly even scalar types and in some situations
changing the size of the stack type.
All these consequences were just wrong and need to be avoided because
they break assumptions of the DLA pipeline, leading to crashes in the
DLA backend, when trying update the model to integrate DLA's results.
This commit prevents all the mentioned wrong manipulation of stack
types, simply by correctly assigning an the size of the stack type from
the beginning, and marking it as non scalar.
Before this commit, DLA's frontend was representing information about
string literals in a way that had a bad outcome: very often, all (or
most) places in the binary that were using string literals ended up
collapsed on the DLA graph on the same node, causing all their types to
be a weird struct.
This was wrong, and it was the result of an aggressive creation of
equality edges.
This commit avoids to emit equality edges, and replaces them with
instance edges, that represent the fact that a call to StringLiteral
actually returns a type that represents a pointer to char.
The inter-procedural part of the DLA frontend connects actual arguments
of function calls with formal arguments of the callee functions, with
instance links at offset 0.
This represents the information that the type pointed-to by the actual
argument has an instance of the type pointed-to by the formal argument
at offset 0.
Before this commit, this was done even when the actual argument was an
integer constant leading to various problems:
1. Most of the times, small integer constants passed as actual
cannot represent valid pointers, leading to graphs bigger than
necessary.
2. Even when an integer constant might actually represent a pointer into
valid memory, if it does it should fall into some segment.
If it does, by the time DLA runs, those integer constants should have
already converted into calls to the special SegmentRef opcode, which
is already handled properly.
3. Finally, those constants end up being very connected in the DLA
graph, creating connections between other nodes that are otherwise
unrelated or very far from each other. This pollutes the graph and
rapidly degrades the quality of the results.
This commit properly guards the code so that the instance-at-offset-0
link between actual and formal arguments is never injected if the actual
argument is an integer constant.
Before this commit the DLA frontend was not ready to handle all the
possible combinations of integer- and pointer-typed arithmetic that was
used to compute SCEVs.
This could cause crashes when dealing with pointer-typed SCEVs.
This commit fixes the issues by converting all pointer-typed expressions
to integers, and resizing integers to the same size before adding them.
Now extractvalue instruction are replaced by dedicated
OpaqueExtractValue custom opcode, that prevents LLVM from doing strange
things with extractvalues during optimizations (such as e.g. sinking).
This is important since extractvalue instructions and struct-typed
values in general in our LLVM IR are not real first-class citizens, but
only a byproduct of the binary lifting process, and they actually
represent bundles of registers that are returned from isolated
functions.
For segmentRef type of the segment and type returned by segmentRef
function are the same.
For cstringLiteral every call returns pointer to 1-byte type. Pointer is
offsetted by value of strlen+1. strlen is fetched from metadata.
Additionally, all uses of cstringLiteral function has same type as the
type of cstringLiteral (pointer to 1-byte).
Giacomo Vercesi