VMA is obsolete and scheduled to be removed. The tests we had in the
test suite before this commit were for a mode of operation that we're
not actively using for decompilation now, and that will be dropped.
This commits just removes those tests.
After updating the function type conversion to be extra strict about
type alignment, the model-to-header tests for all these primitive
types no longer pass: it's no longer valid for a CFT to use any
primitives ABI is not aware of as part of the prototype.
As a simple workaround, this commit replaces all the primitives
used by said prototypes with pointers.
Explicitly casting to uint8_t has the semantics of truncating, in case
the value being casted is larger than 8 bits.
Avoiding the cast default to regular C behavior, where every non-zero
integer is considered true.
The pass has always been redundant, only used to simplify the IR and not
for anything useful.
Recently, after the work done to tidy up casts, it has started to give
problems: turns out ModelGEPRefs without indices are not always
redundant, and removing them can cause `trunc` instructions that then
end pessimizing the C code generation.
This commit drops the pass altogether.
This commit:
1. Introduces an alloca for stack arguments of a function. This enables
us to "write" to stack argument. In order to do so, we simply map the
relevant stack portion to the alloca that, since it's a memory
object, can be `load`'d from and `store`'d to.
Note that `llvm::Argument`s are always scalar since if the original
argument was an aggregate, it would have been passed as a pointer,
which is a scalar.
Note also that previously we were using scalar arguments as if they
were *pointers* to the stack arguments. This commit fixes that too
(and updates the tests accordingly).
2. Introduces an alloca for *scalar* stack arguments of a call site.
The alloca is then mapped to the corresponding part of the stack.
Previously, there was no redirection and negative offsets from
`_stack_frame` would pop up.
This also changes the names that show up in the VSCode-based UI, so that
they are coherent with what's included in the decompiled C code via the
related #include directives.
- Add PrepareLLVMIRForMLIR Pass.
This Pass performs massaging of the LLVM IR
produced by revng so it can be parsed/accepted
for the LLVM MLIR Dialect.
- Introduce new pipeline branch: llvmir-to-mlir.yml.
- Add LLVMIRToMLIR step.
- Add ImportLLVMToMLIRPipe pipe.
The Decompiled container (which use FunctionStringMap) now uses
`.tar.gz` as the container format, as opposed to YAML. Change the
filename of the containers accordingly.
`revng` now requires all pipeline files to have a `Component` field
which tells the command line driver to what component the pipeline
definition belongs to.
* Fix non-PrimitiveTypes with low IDs.
* Ensure we use `revng model compare` to test the model.
* Updates the name to reflect the recent changes in naming convention
and in the way we represent `model::Type::ID`s.
This commit:
* Introduces `_` as a prefix for all non-user entities we emit in
decompiled code.
Also, some names have been changed to be more concise.
Specifically, the following entities have changed:
`_ENUM_UNDERLYING`, `_ABI`, `_REG`, `_padding_at_`,
`_artificial_struct_`, `_artificial_wrapper_`, `_stack`,
`_break_from_loop_`, `_var_`, `_stack_arguments`,
`_artificial_struct_returned_`, `_enum_max_value_`.
* Introduce _PACKED for `__attribute__((packed))`.
* `EnumEntry` name: drop the `EnumType` name prefix.
This analysis will be used for the following features:
1) Edit Type in the Model
2) Edit Function Prototype in the Model
3) Add Type to the Model
It takes C code as an input, parses it and produces a Model
type that represents the C type.
This is necessary because i386 has weird sizes for `long double` that
result in `float86_t` in the model, so we need to pass additional
arguments to the recompilation tests, in order to avoid compiler errors.
Before this commit, both `generic80_t` and `generic96_t` were always
defined as structs containing an array of chars of the proper size.
This ensured that they always had the proper size, but it didn't play
well with recompilation of decompiled C code, because it wasn't possible
to assign e.g. a `float80_t` to a `generic80_t` (or viceversa), which
was the whole point of having `generic80_t` and `generic96_t`.
This commit works around this by making sure that, whenever `float80_t`
(and `float96_t`) is defined, the definition of `generic80_t` (and
respectively of `generic96_t`) always matches, allowing error-free
recompilation of decompiled sources.
This change is intended for the name not to clash with another set of
tests that lives in revng-c.yml.
The first is intended as a set of unittests for model-to-header,
the second is intended to generated headers to test recompilation of
decompiled C code.
This commit guards 128-bits integer typedefs and helpers with:
`#ifdef __SIZEOF_INT128_`, because these are compiler extensions that
are not always guaranteed to be defined (e.g. they are not available
when compiling for x86 32-bits).
Before this commit, we used to decomple UndefValue to the literal 0.
This was causing problems in some cases, such as switch(0 /*undef*/)
where clang was issuing a warning that was impossible do disable without
turning off -Wall alltogether, which is undesirable.
This commit introduces a set of helper functions in
revng-primitive-types.h, that are now used to avoid emitting undef as
constant.
This is more semantically meaningful when looking at the decompiled
code, and it has the nice side effect that it silences the clang
warnings mentioned above.
Now extractvalue instruction are replaced by dedicated
OpaqueExtractValue custom opcode, that prevents LLVM from doing strange
things with extractvalues during optimizations (such as e.g. sinking).
This is important since extractvalue instructions and struct-typed
values in general in our LLVM IR are not real first-class citizens, but
only a byproduct of the binary lifting process, and they actually
represent bundles of registers that are returned from isolated
functions.
Before this commit we were restoring opaque extractvalue instructions to
actual non-opaque extractvalue instructions in the pipeline.
We will not do this anymore, since LLVM ends up messing around too much
with them and it breaks the somewhat assumptions we're making around
values with aggregate types, that in our IR only represent tuples of
registers coming from the binary.
Alessandro Di Federico