Notable changes:
- Split in multiple files the existing revng-merge-dynamic script
- Add the option to merge additional LOAD segments in the resulting
binary
- Align the new .dynstr to a 4 byte boundary
- Ensure the last verneed entry is marked as such (vn_next == 0)
- Ensure LOAD PHDRs are listed in ascending order,
as mandated by ELF spec
RecursiveCoroutines are a facility intended to be used as-drop in
replacement of recursive functions.
They provide the following features.
- They can be written almost as regular recursive functions,
with 4 caveats.
1. A recursive coroutine that returns a type `T`, needs to be declared
to return a `RecursiveCoroutine<T>`.
2. Inside the body of a recursive coroutine, when recursively calling
another recursive coroutine, the recursive call needs to be
prepended by the new keyword `rc_recur`.
3. Inside the body of a recursive coroutine, the `return` statement
needs to be substituted with `rc_return`.
4. When launching a recursive coroutine `A` from a function that is
not a recursive coroutine, `A` needs to be called with the provided
dedicated template wrapper `rc_run`.
The syntax is the following `rc_run(A, arg0, arg1, ...)`.
This is necessary to enable swapping off recursive coroutine and
fall back to regular recursion for debug.
See below for how to do it.
- Unlike regular recursive functions, they don't use the system stack
for recursion. They use a custom heap-allocated stack to manage
recursion. This makes them more robust for implementing recursive
functions that manipulate user-defined input, because they are much
less likely to trigger stack overflow.
- They can be turned off compiling with
`-DDISABLE_RECURSIVE_COROUTINES`, falling back to regular recursion,
for debug purposes.
- They support both direct and indirect recursion, i.e. a recursive
coroutine A can recursively call itself, or it can recursively call
another recursive coroutine B, which in turns recursively calls A.
This is intended to be used by all projects that adopt rev.ng coding
conventions for C++. Each project can create a symbolic link to the
installed .clang-format file, so that IDEs and other dev tools can pick
it up easily while keeping it up-to-date when updating revng.
This enables running the check-revng-conventions script as part of the
build and install process, to generate the .clang-format file for
installation and use from other projects.
This option is enabled with --print-clang-format-config.
This is useful to work around the fact that clang-format configuration
is hard-coded in a file.
Using this option is easier to generate a .clang-format file that can be
dropped in single projects to be picked up by IDE.
After the discovery of new code to be translated, the calls to `newpc`
can be stripped of their variadic arguments (reference to local vars)
in order to let SROA perform more optimization.
`raise_exception_helper` must not return to its caller. Should
`_Unwind_RaiseException` return, something will have gone wrong
with the personality routine; yet this should never happen.
This way we might also save a few bytes and hint the compiler to
avoid storing the callee-saved regs / allocating a new frame.
This assertion was executed in the `runOnModule` method of the GCBI
pass, but it is too strict.
Asserting that Dispatcher != nullptr during the execution of the pass
prevents the pass from successfully running on a Module without a
Dispatcher.
This is unfortunate, because some passes that depend on GCBI in revng-c
actually do that. They do so because they are not really interested in
the Dispatcher at all. They only use GCBI to access information on the
Stack Pointer.
In fact, the check for Dispatcher being != from nullptr is already
performed also in the `dispatcher()` method which is the sane thing to
do. This commit removes the assertion from the `runOnModule` method and
leaves it in the `dispatcher` method.
This allows to run the pass successfully even on a Module without the
Dispatcher, while not changing the contract of this pass (i.e. that when
you call the `dispatcher` method you get a nonnull pointer).
Sorting the BasicBlocks on which DisjointRanges works is detrimental for
performance. Using a random order takes less time. This is due to the
fact that the number of BasicBlocks to analyze is significantly smaller
than the whole list of BasicBlocks.
This simple commit reduces the number of times we query the size of the
`BasicBlock` list of a `Function` during the final reodering of blocks
before emission.
This change introduces a 25% speedup when lifting `/bin/bash`.
It is important to let the pass manager go out of scope ASAP:
LazyValueInfo registers a lot of callbacks to get notified when a Value
is destroyed, slowing down OptimizedFunction->eraseFromParent
enormously.
This commit introduces a speedup of approximately 25% when lifting
`/bin/bash`.
The format file has also been renamed to revng-clang-format-style-file.
The check-revng-conventions scripts now always uses the same format
file, unless otherwise specified with the new option
--use-local-clang-format-file.
In this way, the check-revng-conventions uses the same format in all the
projects by default, but if a project needs to customize it (e.g.
cold-revng which follows the Qt style) it can use the new flag to
fallback to using the local .clang-format file.
This commit introduces the PruneRetSuccessors pass, whose role is to
identify all the indirect jumps whose devirtualized destinations
correspond to return addresses. In fact, they are most likely to be
return instructions and devirtualizing them is always detrimental.
After combining two AS objects, removing an ASOContent in the cleanup
phase may lead to a mismatch in the CSVs promoted to function argument,
with some registers actually being used. In most cases, this results in
promoting only one or few alive registers as function argument.
Alessandro Di Federico