`ValueMaterializer` is a rewrite of what was called `AdvancedValueInfo`
which follows the same principles.
The main benefits over the old version is:
* We materialize the data-flow graph and the CFG of the relevant part of
root. This makes debugging significantly easier.
* We drop the old MonotoneFramework infrastructure in favor of
getMaximalFixedPoint.
* We significantly reduce the amount of queries we make to
AdvancedValueInfo.
Sometimes code performs an indirect jump without changing the value of
the PC. In most cases this is due to non-code or some other faulty
situation, but it is in principle possible that an instruction performs
an indirect branch to its own address.
This commit ensures that this situation does not end up in an hard
failure.
By using this class we can create ptml::Tags without
XML tags. It is useful in the revng-c part when we
want to generate Plain C. All PTML Tags, from now on,
should be created via this class only.
In addition, port `Yield` library to be using this.
This also reorders the enum, because when two tags collide (they have
the same `from` and `to` points, they are sorted based on the enum
values.
The new order ensures that the values we are more likely to choose
to preserve are closer to the bottom. Since each token can only have one
type associated with it, we choose the lowest one by default.
I found that it leads to better looking code when the check of whether
the range in question even has enough elements to skip is inside
the helper.
As such a separate type of skip entry point was introduced: one that
allows to iterate over the container pairwise
Now, instead of asserting, the loop just does nothing in cases like
```cpp
for (const auto &Element : zip_pairs(make_empty_range())
do_stuff();
```
Drops the comment about an attempt to switch to the absolute targets
and sets `setPrintBranchImmAsAddress` to `false` no matter what
immediate style is selected.
`IsDynamicallyCalledFrom` is removed in favour of `IsCalledFrom`.
Looking at just how similar the actual uses of both are, there's not
much reason to keep them separate.
We used to ignore CFEPs that matched the starting address of a basic
block of a previously detect function.
We now also exclude such CFEPs even if the candidate is *part* of an
existing block.
This is done mainly so that downstream passes do not need to run
`CollectCFG` to store information that has already been computed but not
serialized.
This come at the cost of computing the CFG also of functions we don't
want to analyze in `DetectABI`.
Under certain conditions, upon import, functions where not being added
`ExportedNames`, which was preventing them from finding the prototypes
from dynamic libraries' debug information.
This commit ensure the BaseAddress is propagate as appropriate to all
levels of the importers and that it is ignored for executables
(non-PIC).
This was a recurring source of importing the same function twice, once
relocated, once not.
Alessandro Di Federico