Explicitly list the functions whose prototype should be serialized
in the `revng_helpers` header. This is more robust with respect to
future opcodes added in the IR.
Calls to `OpaqueExtractValue()` are meant to replace `extractvalue`s
found in the LLVM IR. Since the type of an `OpaqueExtractValue` is
identified by both the return type (extracted value) and the first
argument's type (aggregate operand of the `extractvalue` instruction),
we need to consider both when building the associated FunctionPool.
Previously, we were identifying each `OpaqueExtractValue` variant using
only the returned value, which was wrong. In fact, if we have two
`extractvalue` instructions that extract a value of the same type
(e.g. i32) from two different aggregate types (e.g. structA and
structB), we have to define two different `OpaqueExtractValue`: one
that returns an i32 and has a parameter of type structA, and one that
returns an i32 and has a parameter of structB. If we use only the
return type, we are not able to distinguish the two.
Before this commit we were using a suboptimal API that often resulted in
expressions with many zeros for the 0 constant, e.g. 0000000 instead of
just 0.
This commit fixes the problem.
Before this commit, SegregateStackAccessesPass always expected to find
calls stack_size_at_call_site markers injected by
InjectStackSizeProbesAtCallSitesPass.
This is not always true, because aggressive LLVM optimizations can
remove dead code.
As an example, if the user or some analysis earlier in the pipeline
wrongly marks registers as non-arguments, the optimization pipeline will
throw away and eliminate everything that descends from the initial
values of those registers.
This commit enables SegregateStackAccessesPass to cope with calls to
stack_size_at_call_site that were eliminated, and keep going just
considering the calls that are still there.
This pass was never implemented and we don't have plans to do it soon.
This commit just drops it to reduce the noise.
Whenever we decide to implement something similar we'll do it from
scratch.
This commit adds the newly implemented functionality in PipelineC both
in revng.api and the graphql api, allowing:
* retrieval of global variable names
* unwrapping of a single target
* execution of analyses
Moving it was causing the address of the model to change, while for the
functionality of revng-pipeline we need it to be stable.
So we pay the price of expensive copy, for the sake of downstream
stability.
This commit introduces a reusable function to compact
pipeline::TargetLists that represent functions.
Initially this reasoning was only needed by TaggedFunctionKind, but now
also FunctionStringMap needs it, and potentially others in the future,
so it makes sense to keep only a single implementation for it instead of
duplicating code (and likely bugs).
The beautification library was split into a separate library for
historical reason, having to do with LLVM passes, their dependencies,
and dirty hacks we had around.
Now the LLVM passes, and the hacks are gone, so we can merge back
everything together.
Now that the late stage of the decompilation pipeline is managed with
revng-pipeline, and we have a standalone tool for decompilation, we
have no need to use LLVM passes anymore for those stages.
This commit also renames the directories to avoid the confusing Pass
suffix, not what LLVM passes are gone.
This commit replace the old CBackendPass with a standalone tool:
revng-decompile.
This pass at the moment runs the three stages of decompilation:
- CFG restructuring
- Beautify GHAST
- C Code generation
This flag was used with the old C backend to decompile only a single
function from a binary.
The logic of selecting functions in a binary for decompilation is now
part of revng-pipeline, so the -single-decompilation option and the
associated TargetFunctionOption library can be dropped.
Alvise de Faveri