Unless you explicitly need byte-matching decompilation, there are significantly faster ways to produce a decompilation/C which is functionally equivalent. I need to post about this. What's been working for me is that for every function, Agent A is tasked with writing some code which is semantically equivalent to the original assembly, but not necessarily exactly the same. Agent A also writes tests. Agent A submits the implementation of the function and tests to the harness for it to judge. The harness runs both the original function and the submitted function in a virtual machine/simulator/emulator (the tests define function inputs and starting state). The harness will only accept the implementation if 1) the read/write sequence to RAM is identical to the original function's, and 2) there must be complete line and branch coverage of the original function being decompiled.

I've found this to be robust for decompiling games, while giving the agents enough freedom to write code that is readable and not waste a ton of time making sure e.g. instruction ordering, register assignments, etc. are all exactly the same. For me, having byte-matching decompilation is only one way to produce a decompilation I know is faithful to the original. This "high-level decompilation" process I just described is something agents can do much more quickly.

▲

j2kun 4 hours ago | parent | next [-]

Functional equivalence here, of course, depends on the completeness of the test suite, where byte-identical compiled artifacts does not.

(For example, your approach would not necessarily catch all the same overflow behaviors; the OP expressly claimed that "replicating all bugs" was also important, and many bugs are caused by certain overflow behaviors)

▲

nine_k 2 hours ago | parent | next [-]

> catch all the same overflow behaviors

So you're looking not just for functional but also dysfunctional equivalence %)

	▲	8note 2 hours ago \| parent [-]
		no, thats still functional here. the bugs have to be the same, such that speed runs could still run correctly

▲

SubiculumCode 4 hours ago | parent | prev [-]

Byte exact seems only of interest to preserve known bugs etc for cheats/shortcuts/etc.

▲

j2kun 4 hours ago | parent | next [-]

That may be true, but I hate it when people repeat the false idea that functional equivalence requires only a test suite that has full branch/line coverage. Call me triggered :)

That said, I would probably follow this same approach if I were to do this, but with extensive randomized testing as well.

	▲	hedgehog 4 hours ago \| parent [-]
		You can do the process in stages. Do the first decompilation mechanically (no LLM), use a SMT solver to show it builds to an equivalent binary to the original, and then use LLM to clean up the code into something idiomatic with the benefit of a correct binary built with the new toolchain. This helps when you want to port across languages or toolchains, and helps protect against toolchain bugs.

▲

kg 2 hours ago | parent | prev [-]

For anything with recorded replays or multiplayer you need to preserve known and unknown bugs for compatibility reasons, not just for cheating.

▲

SubiculumCode 4 hours ago | parent | prev [-]

So you restricted it to implementing the same function (same inputs,outputs, dependencies as original?) and prevented the agents from making design decisions by keeping it's scope restricted?

	▲	brandonpelfrey 4 hours ago \| parent [-]
		Yes. It can gain more context, but this has been enough. Note, there is also a notion of adversarial review layered on top in which it tries to poke holes in the test plan "you didn't handle this case of XYZ". It isn't actually perfect as a parallel thread said it may miss things like wrapping behaviors. In practice, it's very effective.