The `StackArgumentsType` field of `RawFunctionType` was the only
cross-reference between `model::Type`s that did not use
`model::QualifiedType` but a naked `TupleTreeReference`.
Switching it to `QualifiedType` make all cross-references across
`model::Type`s homogeneous.
This was one of the few places left in the type system where a
`model::Type` referred to another one not using QualifiedType, but a
naked `TupleTreeReference`.
Switching it to be a `model::QualifiedType` makes cross-references
between `model::Type`s more homogenenous, requiring less corner-cases
to handle for whoever manipulates types.
EarlyFunctionAnalysis now can be invoked to schedule a full
ABI analysis over the collected functions via `--detect-abi`
option, or it can limit itself to simply recover the CFG and
serialize it onto the LLVM IR via `--collect-cfg` option.
The control-flow graph and all its hierarchy components
have been moved from `model` to `efa`. The CFG is now
serialized onto the LLVM IR module as a metadata.
The collection of the function entry-points has now been separated
from EarlyFunctionAnalysis into two distinct passes: the first one,
which collects functions which are in call-sites of a direct call,
and the second one which collects code pointers in `.rodata` (e.g.,
function pointers, vtables; jump-tables are possibly skipped).
Missing `#include "revng/Pipeline/Loader.h"` causes compilation error
when calling `Loader.registerLLVMPass<LLVMPass>(Name);`.
This is a problem since whoever includes `RegisterLLVMPass.h` should
include `Loader.h` **before** `RegisterLLVMPass.h` to compile without
errors. This is subject to breakage if `Loader.h` ever changes name and
`clang-format` starts reordering the include **after**
`RegisterLLVMPass.h`.
This commit inlcudes `Loader.h` directly in `RegisterLLVMPass.h` to fix
the root cause.
This commit adds two method for OpaqueFunctionsPool that use
a pointer to `llvm::Type` (or a class derived from `llvm::Type`) as key.
Both methods are used to initialize the pool with pre-existing functions
inside an `llvm::Module` that match a specific `FunctionTags::Tag`:
- `initializeFromReturnType` uses the return `llvm::Type` of the
function as key in the pool
- `initializeFromNthArgType` takes an additional argument which is an
index N, and uses the return `llvm::Type` of the N-th argument as a
key in the pool
These methods are useful for avoiding unnecessary proliferation of
opaque functions in an `llvm::Module`, re-using the existing ones
instead if they are already present.
Now all the generated `.cpp` include `Binary.h`. This ensures we don't
trigger the wrong concept due to forward declarations.
Also, this commit introduces a couple of `static_assert`s which should
enable us to early identification of similar problems.
Massimo Fioravanti