revng VS revng-qa

We should probably add a warning about `source ./environment`.

Now, let's get to each of your comments :D

> though thankfully not LD_LIBRARY_PATH

We spent a lot of time to have a completely self-contained set of binaries where each ELF refers to its dependencies through relative paths. LD_LIBRARY_PATH is evil.

> Mostly prefixed "HARD_"

Those are just used by our compiler wrappers, I don't think those environment variables collide with anything in practice.

> It sets `AWS_EC2_METADATA_DISABLED="true"`

Original discussion: https://github.com/revng/revng/pull/309#discussion_r12805759...

I guess we could patch the AWS SDK to avoid this.

Nielson & Nielson literally saved my PhD and enabled the creation of the company. I'm so grateful.

Do you have any contact? It'd be cool to invite one of the authors to our weekly internal meetings.

> the authors have written a prequel

Oh crap, that's great!

Honestly, we use Chapter 2 a lot, it already provides so much value. And in fact, you could write a whole book only about that.

Here's our C++ implementation of MFP:

    https://github.com/revng/revng/blob/develop/include/revng/MFP/MFP.h#L66

I'm not certain, but my best guess right now is that the non-open-source games are going through a static binary translator (like this one). Going from a strong-memory-model ISA like x86_64 to a weak-memory-model ISA like ARM, can present performance challenges when memory fencing is added.

C++ 20 coroutines: we employ them to achieve "stackless C++";

C++20 Coroutines: we employ them to safely and idiomatically transistions from UI thread and long-running computation threads and "stackless C++""

> the binary code to LLVM IR uplifting loses a lot of context

Losing context is good in order to ensure you properly decoupled the frontend from the rest of the pipeline.

We don't even keep track of what a "call" instruction is, we re-detect it on the LLVM IR.

One reason you may want to preserve context is to let the user know where a specific piece of lifted code originated from. In order to preserve this information, we exploit LLVM's debugging metadata and it works pretty well. There's some loss there, but LLVM transformations strive to preserve it.

After all, imagine you have `add rax, 4; add rax, 4`, you'll want to optimize it to a +8 and you'll either have to decide if you want to associate your +8 operation with the first or the second instruction.

> the binary code to LLVM IR uplifting loses a lot of [...] semantics information

Not sure what you mean here, we use QEMU as a lifter and that's very accurate in terms of semantics.

I'm not sure what MIR and Swift IR have to do with the discussion, those are higher level IRs for specific languages. LLVM is rather low level and it's language agnostic.

However, for going beyond lifting, i.e., decompilation, it's true that LLVM shows some significant limitations. That's why we're rolling our own MLIR dialect, but we can still benefit of all the MLIR/LLVM infrastructure, optimizations and analyses. We're not starting from scratch.

> emulating pieces of the code sparsely to figure out indirect jumps and so on

It's hard to emulate without starting from the beginning. Maybe you're thinking about symbolic execution?

In any case, rev.ng does not emulate and does not do any symbolic execution: we have a data-flow analysis that detects destinations of indirect jumps and it's pretty scalable and effective. Example of things we handle: https://github.com/revng/revng-qa/blob/master/share/revng/te...