renvg.h should not use model headers, however, currently it does. This,
combined with the fact that the revngSupport library did not depend on
revngModel or the header generation led to non-deterministic build
failures.
Before this commit the bug can be found by:
orc clean revng
orc uninstall revng
orc configure revng
orc shell -c revng ninja renvgSupport
The error should manifest itself as some generated headers missing.
The proper fix would be to rewrite revng.h so that it does not uses the
model.
This commits drop an old BeautifyGHAST's dependency on
MarkForSerialization.
This dependency was required because the beautification process makes
some choices (e.g. on short-circuiting ifs) based on knowledge of how
many instructions in a given basic block have side effects.
Informally speaking, if a basic block contains an instructions with side
effects, it cannot be moved before around "crossing" other stuff with
side effects. This is why it was necessary for BeautifyGHAST to know
about side effects.
Information about side effects was computed by BeautifyGHAST using
MarkForSerialization until now, but it was not properly used.
It was more like wishful thinking about what we wanted to do, but we
never fixed it.
So this commit takes a step in fixing this:
- drops dependency in BeautifyGHAST from MarkForSerialization, which was
there but not used;
- starts taking the same information from calls to SerializationMarkers,
if they are available in the IR.
Now, in all the decompilation pipelines we have in place, we don't
inject SerializationMarkers before BeautifyGHAST yet, so the behavior
in those pipelines is totally unmodified for what concerns side
effects.
However, for all new decompilation pipelines that we will build, we will
run IRCanonicalization passes before BeautifyGHAST. In this way, the IR
reaching BeautifyGHAST will have SerializationMarkers in place, and the
beautification process will work as intended.
This commit adds a second argument to functions in the family of
SerializationMarker. The second argument is a boolean.
If it's true, it represents the information that the marked
llvm::Instruction was marked because it had side effects.
This information is necessary for various beautification tasks on the
GHAST, and we want it on the IR in order to be able to switch away from
the old MarkForSerializationPass.
Model classes are now described by a YAML document, which is used to
generate C++ headers containing classes and all the boilerplate
required for YAML serialization/deserialization, usage in
SortedVectors, etc. See the README in include/revng/Model for more
info.
Remove the logic for detecting Instructions with duplicated uses
introduced by control-flow restructuring (the use is duplicated, but the
instruction is not).
By dropping this detection, we'll end up not marking for serialization
some Instructions. Hence, when emitting C code, such Instructions will
just be emitted as inline expressions, without declaring a dedicated
local variable to hold their value. This is somehow suboptimal w.r.t the
fact that the expression will be emitted many times, one for each
duplicated use. However, this is not semantically incorrect, just
verbose.
On the other hand, the logic for detecting Instructions with duplicated
uses has always been subtly broken, because it only looked at the number
of duplicates for a given basic block introduced by control-flow
restructuring.
This information is not enough to detect Instructions with duplicated
uses. Proper detection should actually be based on GHAST.
`main` is not in all cases a dynamically exported symbol, therefore,
it's not safe to rely on it.
This commit switches to use `PathList`'s `getCurrentExecutableFullPath`,
which reads `/proc/self/exe`.
StringRef::data() does not ensure that the string is zero terminated,
thus when printed it can contain more data than expected.
Specifically, this triggered the reported name of the registers to be
incorrect, and this manifested itself as wrong inline assembly emitted.
The constructor now accepts a llvm::object::Binary directly rather than
a path. Will be used by the revng-pipeline which will retain ownership
of the binary.
The following bugs have been fixed:
* PromoteCSV no longer mixes `alloca` with other instructions, which is
a convention in LLVM IR that some passes rely upon.
* Before this commit, we were detecting if *calls to CSV initializers*
where already present in order to reuse them, but this was not right,
we need to reuse the *alloca* instructions they are associated
with. This commit does exaclty that.
This commit makes sure that GeneratedCodeBasicInfo can be used even in
absence of the `root`.
This also ensure that no time is wasted on brief/focused pipelines that
do not care about analyzing each basic block in the `root` function.
Massimo Fioravanti