This commit further centralizes the creation of allocas + ptrtoint. The
creation of these pair of instructions is problematic when the size of a
pointer in the input and target architecture differ.
In fact, in such cases, LLVM turns trunc into masking the integer to
suppresse the high bits. This results in problematic code.
This commit introduces an assumption that ensures LLVM does not do that.
When using revng through `revng daemon` the variable `InputPath` is not
populated, leading to `lddtree` failing silently. Fall back to the input
binary in the resume directory in case the the `InputPath` variable is
empty.
Clean up the `ProgramRunner` class:
* use llvm-provided wrappers and system-agnostic variables to compute
the `Paths` variable
* pre-compute the list of path variables so it's not re-computed on
every invocation of `run` or `isProgramAvailable`
* Wrap the logging code so that it's not triggered if the logger is
disabled
Change the `joinError` functions to have stronger guarantees when used:
* Change the template signature to `RangeOf` to ensure that the
container has `llvm::Error`s.
* Check that the size of the passed container is actually positive
before deferencing `.begin()`.
Implement the DAGify pass. This pass, using the results exposed by the
`GenericRegionInfo` analysis, transforms all the retreating edges of
each identified `GenericRegion`, processed in a bottom-up fashion, into
a `goto` edge on the `ScopeGraph`.
Do not assert if the marker function is not present in the input IR, the
`Builder` instantiation takes care of its on-the-fly declaration
instantiation.
Add the `revng::cantFail` function which allows to wrap functions with
`std::error_code` and check their result. This is analogous to
`llvm::cantFail` for `llvm::Error`.
This commit changes the prototype of getCopeType, so that it now takes 2
arguments.
1. The llvm::Type returned by the Copy function. This can be any scalar
llvm::Type.
2. The llvm::type of the argument representing the reference to the
value being copied. This should be a pointer-sized integer, where
pointer-sized means with the same size of a pointer in the
architecture in the input binary.
The second argument is not strictly necessary for now, because the whole
decompilation framework expects a binary with a single architecture,
hence a well defined unambiguous pointer size.
This will be used fully only when we start supporting multiple binaries.
Whenever that happens, if we haven't already fully dropped the Copy
helper function we will have to update the associated
OpaqueFunctionsPool to a type pair as key: the return type and the type
of the argument.
Lauri Vasama