Generalize `FunctionStringMap` into `detail::GenericStringMap`, which
supports any `Depth=1` rank. `FunctionStringMap` remains as an `using`
with `Rank = ranks::Function`.
Replace the stub implementation of invalidation with the proper
implementation. A ReadPathCache is added to each global so that it can
keep tracks of what target are associated to which read paths.
After the changes to the direction `CrossRelation` output is parsed,
the slicer wasn't updated accordingly. Because of that, the slices were
as if they were produced backwards.
As for the full graph, since it starts from an artificially added node
that doesn't have any successors by definition - it was appearing empty
(only the non-emittable "root" node was present).
HexDumpPipe dumps content of binary file in the similar way as hexdump
tool with addition of PTML markup for instructions addresses.
Continuous parts of binary code are wrapped with <span
data-location-definition=""></span> where data-location-definition
attribute contains Entry/BasicBlock/Instruction addresses in generic
form. <span> tags can be nested if byte(s) belong to many instructions
in code.
At the end of the line every <span> is closed and opened on the next
line again if it still applies to the next byte.
MetaAddress are converted to IntervalMetaAddress (which implements own,
optional-less operator-) and stored in boost::icl::intruval_map. This
map is used to get addresses of instructions to which each byte belongs.
Not every case can benefit from extra liniency, so they were manually
reviewed on a case by case basis.
Additionally, this drops a couple of "this should be a non-strict
specialization" commits, because of a bug with clang
(see the GenericGraph concepts rework commit for more details) as
to avoid confusion (we wouldn't want anyone trying to solve these
"todo"s) until the clang struct type deduction is fixed. Especially
considering that there are currently no cases where these softer
versions would be beneficial (we never inherit from templates in
question).
By using this class we can create ptml::Tags without
XML tags. It is useful in the revng-c part when we
want to generate Plain C. All PTML Tags, from now on,
should be created via this class only.
In addition, port `Yield` library to be using this.
This also reorders the enum, because when two tags collide (they have
the same `from` and `to` points, they are sorted based on the enum
values.
The new order ensures that the values we are more likely to choose
to preserve are closer to the bottom. Since each token can only have one
type associated with it, we choose the lowest one by default.
Drops the comment about an attempt to switch to the absolute targets
and sets `setPrintBranchImmAsAddress` to `false` no matter what
immediate style is selected.
`IsDynamicallyCalledFrom` is removed in favour of `IsCalledFrom`.
Looking at just how similar the actual uses of both are, there's not
much reason to keep them separate.
Before this fix, graph preparation sometimes left extra long-edges not
connected to anything in. They were not visible after the SVG
exportation, but they were making edge routing worse (by forcing
horizontal lanes to appear where they shouldn't be - thus spacing nodes
further away from each other than necessary).
Ivan Krysak