Add an engine for running VMA in different modes. User can:
- Decide how to initialize the colors (e.g. from the Model or from
the LLVM IR)
- Decide what to do with the final TFG obtained by VMA
- Decide whether or not the Mincut algorithm should run
1. Add a common helper to traverse ModelGEPs (`traverseModelGEP`)
2. Add a centralized way to deduce the model type of values that
have strong model information attached to them (e.g. isolated
functions and ModelGEPs)
3. Add a similar helper for deducing formal types of operands in known
cases
ModelGEP calls in LLVM IR now return an integer that has the same
size of the field being addressed by the ModelGEP.
AddressOf calls, instead, can accept any integer size as argument but
always return a pointer-sized integer.
If we find values to be used outside their scope, we need to always
mark them for assignment, so that they have a dedicated variable that
is declared in the right scope. To do this we:
1. Export the logic that decides if a value needs a top-scope variable
in a public header, to be used by both `VariableScopeAnalysis` and
`MarkAssignments`.
2. Add the `HasUsesOutsideBB` reason for assignment markers
Add `ReadsMemory` and `WritesMemory` Tags and restructure the
logic that decides whether two instructions are interfering
as follows:
1. Consider `Store`s and anything with a `WritesMemory` tag as
having side effects
2. Consider all the `TaintSet` of an instruction when deciding
if two instructions interfere
3. Consider both `ReadsMemory` and `WritesMemory` Tags when
deciding interference
A simple pass that maps LLVM IR instructions to C operators,
taking into account their precedence and associativity to
emit nice-looking parenthesized expressions.
A pass that strips the casts off from some instructions, including
`ModelGEP`s, general function calls, return and store ones, and
embeds the cast into new dedicated `ModelCast` function calls.
When creating the DLA graph, we want to avoid inserting `instanceOf`
edges with huge offsets, so we set a limit to 64K.
This is a workaround to handle cases in which we make wrong decisions
about the base address of a SCEV expression. One of the situations in
which this occurs are expressions such as `&val + BIG_CONST`, for which
we always identify `%val` as the address and `BIG_CONST` as the offset.
When fixing this case, we should still verify that this never happens.
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.
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.
This library contains what were previously 6 separate libraries:
- FilterForDecompilation
- MakeEnvNull
- RemoveCpuLoopStore
- RemoveExceptionCalls
- RemoveLLVMDbgIntrinsics
- RemoveREmoveNewPCCalls
These libraries are now aggregated, and will be merged in single
llvm::Pass for migrating revng-c to the new revng pipelines
infrastructure.
For now they are unused, but they will be used by the first
revng-c pipeline using revng::pipeline, that will strip off all the
artifacts left from the lifting process.
This pass was used to remove llvm.addume(false) calls that caused some
paths of the CFG to be marked as unreachable and optimized away.
The insertion of calls to `llvm.assume(false)` calls was happening due
to the handling of the PC around `opaquepc` calls, generated by `revng`.
The calls to `opaquepc` are no longer emitted by `revng`, nor is the
special handling of the PC around them that causes `llvm.assume(false)`
calls to be emitted.
Hence, the RemoveLLVMAssumeCalls pass to no longer makes sense. This
commit removes it.
This library replaces the old AddIRSerializationMarkers, cleaning up a
lot of historcal baggage, merging Liveness and MarkAnalysis, and
adopting a more accurate naming across all the codebase.
These two parts of the code needed to be separated into libraries
because they were used both by the old C backend and by
IRCanonicalization.
Now that the old C backend is dead, they have been incorporated into
IRCanonicalization.
Further changes are necessary to strip away the last leftovers of the
old C backend from MarkAnalysis.
Pietro Fezzardi