This reworks NameBuilder to ease the transition to the system where
the model will be guaranteed to never contain any name collisions, both
between user-specified names and the automatic ones.
This commit further centralizes the creation of allocas + ptrtoint. The
creation of these pair of instructions is problematic when the size of a
pointer in the input and target architecture differ.
In fact, in such cases, LLVM turns trunc into masking the integer to
suppresse the high bits. This results in problematic code.
This commit introduces an assumption that ensures LLVM does not do that.
Introduce LegacySegregateStackAccessesPipe
This commit restructures the SegregateStackAccesses pass and
SegregateStackAccessesPipe so that they can have 2 modes of operations:
1. Legacy, with the same behavior as the old version, injecting local
variables as custom llvm::Functions representing opcodes, such as
LocalVariable, AddressOf, StackFrameAllocator, and CallStackArguments
allocator.
2. Non-legacy, that is meant to operate with the new LocalVariableHelper
to inject local variables as regular alloca instructions, with
additional metadata to discriminate among them.
This commit renames the old SegregateStackAccessesPipe to
LegacySegregateStackAccessesPipe.
It then re-uses the old SegregateStackAccessesPipe name for a new pipe,
meant to work in non-legacy mode.
The pipeline definition YAML file is updated to keep using the legacy
version for now.
For now the implementation is still the same.
This is preliminary to unifying the creation and handling of local
variable declarations, to simplify switching over to local variables
represented by plain allocas.
Before this commit, the code was making a couple of broken assumptions on
OpaqueExtractValues
- that OpaqueExtractValues were always ordered in the same way as struct
fields (e.g. the OpaqueExtractValue extracting field 0 was always the
first use of the struct-typed value it was extracting from)
- that there was always one and exactly one OpaqueExtractValue for each
field index in the struct
This commit fixes the issue, while reusing available facilities for
dealing with OpaqueExtractValues.
This commit heavily reworks how we handle returned values, making things
a bit more elegant.
Apart from this, it fixes how were handling types that on the model are
aggregates but were being returned via registers on the IR.
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 commit splits in two stages handleCallSite and
handleMemoryAccess. Running the latter after all the call sites have
been handled, is necessary in order to properly replace certain memory
accesses targeting stack arguments of a call site.
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.
Before this commit, we were only copying the metadata attached to the
CallInst, but we need to copy also the attributes, otherwise we might
lose important information, such as `nomerge`.
We were not properly handling functions with a `CABIFunctionType` whose
return value covered multiple registers (e.g., a `uint64_t` being
returned through two registers in i386).
Also, we were not correctly handling `CABIFunctionType` returning a
integer type that is smaller than the register containing it (e.g., a
`uint32_t` being returned through `rax` in x86-64).
This commit fixes both situations.
If a function was returning a scalar, we used to forward the return type
from before Segregate. However, this was not OK in case a return value
was in a 64-bit register, but was actually using only the lower 32-bits.
This commit improves handling of such situation.
Ivan Krysak