Add a python interface (`revng.profile`) for interacting with the rev.ng
infrastructure as a whole; either through the CLI (`CLIProject`) or the
GraphQL API (`DaemonProject`).
The tests was testing if a function whose entry address is the target of
load was identified as a function or not (it shouldn't).
This test was passing accidentally. This has not been supported since
the introduction of `RootAnalyzer`. In order to support this again, we
need to resurrect `processLoadsAndStores`.
This commit ensures that parts of the model that must point to code
(specifically `Binary::EntryPoint`, `Binary::ExtraCodeAddresses` and
`Function::Entry`) actually point to a segment mapped as +x.
The DLAStep SimplifyInstanceAtOffset0 now only triggers if the parent
node has the child-at-offset-0 node as its only successor, or when the
child-at-offset-0 doesn't have other predecessors.
Doing this guarantees that it's impossible for another predecessor of
the child-at-offset-0 to start seeing memory accesses that were
initially relative to the parent.
This condition is slightly more restrictive than the previous one, but
it takes into consideration some far reaching consequences.
If SimplifyInstanceAtOffset0 aggressively like we did before, DLA can
end up inferring types in some memory locations, like executable
segments, for which there aren't clues in the binary.
This isn't bad per se, but if DLA does that, the newly recovered type is
identified as non-executable data, causing misdecompilation because
rev.ng doesn't decompile memory regions that it understands as non
executable.
This commit, making SimplifyInstanceAtOffset0 less aggressive, makes it
play better with the rest of the assumptions of the decompilation
pipeline.
It also relaxes a decompilation test that was previously working by
chance and that was effectively beyond the current expressive power of
reasoning for DLA at the moment.
Before this commit, the test was implicitly relying on control-flow
recovery and on the specific order of the then/else scopes in an
if-statement.
This commit relaxes that requirement, since it's not part of what the
test is designed to test.
We introduce a new LLVM Pass that should detect implicit
casts, by marking the 3rd argument of ModelCast as `true`.
The backend will omit printing a cast expression if the
ModelCast is implicit one.
Giacomo Vercesi