These functions can be used in conjunction to dump the Model on a
file during a gdb session, for example:
```
(gdb) p writeToFile(Model->toString(), "/tmp/model.yaml")
```
Without this attribute, newer versions of llvm are not able to
remove calls to `ReadOnly` functions whose return value is unused.
This is instead the expected behavior for the functions that are
generated by `revng` with the `ReadOnly` attribute.
Before this commit, SerializeModelPass and SerializeModelWrapperPass had
hard dependencies on the passes that load the model from LLVM-IR.
This commit makes this dependency optional. When the passes for model
serialization are executed, if they see that nobody requested to load
the model, they will not try to serialize it.
This prevents them from crashing when running in pipelines that only
contain passes that ignore the model.
This is particularly beneficial because `revng opt` automatically adds
`-serialize-model` at the end of each pipeline and, before this commit,
this meant that `revng opt` could not be used for unit-testing simple
llvm passes that do not use the model.
With this commit, `revng opt` can be used for unit-tests, even on LLVM IR
with missing model.
* Introduce some documentation for the model.
* Improve the way enums are serialized/deserialized.
* Mark certain fields of model data structures as optional.
* introduces some error messages during model validation.
This commit reserves the "unnamed_" prefix for revng.
The first use of this reserved prefix is in `model::Type`s
`CustomName`s and `model::Identifier`s.
This commit also makes the `verify()` method stricter for
`model::Identifier` so that an `Identifier` whose name starts with the
reserved prefix does fails verification.
This commit changes the `TupleTree::deserialize` method to return an
`llvm::ErrorOr<TupleTree>`, enabling users to choose their policies on
error reporting.
This commit introduces the type system of the model along with several
various other improvements to the model and its users.
* Introduce the type system.
* Introduce possibility to tag certain fields in the model as to be
optional during YAML serialization.
* All the `Name` fields have been replaced in favor of `CustomName` plus
a `name` method that will use `CustomName` if available, or an
automatically generated name otherwise.
* Make TupleTreeReferences behavior more robust: now you either need to
have a valid pointer to `Root` and a `Path` or be default constructed
(`nullptr` for `Root` and an empty `Path`). Any other configuration is
invalid.
* The type system introduces `RawFunctionType`: this superseds the
previous way in which we were specifying arguments and return
values. Users of such information have been updated accordingly.
The previous design returned a model::Binary &, which did not allow
users writing the model to properly initialize cross references between
different parts of the model.
With llvm-12 thera are more stringent requirement on the propagation of
DebugLoc on CallInst and InvokeInst.
Various CallInst and InvokeInst created during lifting did not fulfill
these requirements, causing the Module to not verify() with llvm-12.
This commit fixes the problem, properly propagating the debug locations.
Checking if a `SwitchInst` has a certain case triggers a linear search.
When we have *a lot* of jump targets this is an issue.
This commit assumes that when we add a case to a dispatcher, that case
is not already there.
This commit drops the KeyTraits in favor of a std::any-like solution.
Basically, we type erase any key the user wants to employ, just exposing
a virtual version of the destructor, a comparison operator and a clone
primitive.
RemoveExceptionalCalls is a simple pass whose goal is to drop all the
calls to functions marked as `Exceptional` and replace them with an
`UnrechableInst`.
This is mainly useful in the decompilation pipeline.
This commit takes out of EnforceABI the part taking care of creating
wrappers for calls to helpers and promoting CSV to local variables.
This decoupling, enables to run -promote-csvs multiple times, for
instance after inlining.
FunctionTags goal is to solve the long-standing problem of identifying
what type of function are we dealing with. Is it a lifted function? An
helper?
Now we have a sane way to determine this using Metadata and a proper
API.
Antonio Frighetto