You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if you have a dogbolt link where two tools disagree, there's no way to know which one is correct. (e.g. BinaryNinja vs Hex-Rays here)
Adding a "disassembly" pane would give a source of truth, to allow users to understand what the input to the decompilers actually was, and which one is correct.
The text was updated successfully, but these errors were encountered:
This is a good idea although it is more nuanced than "just slap objdump on it," considering there are many different disassemblers for many platforms and they often disagree. Also there's the eternal challenge of extracting the text segment and knowing which regions are actually code. We could add runners for many different disassemblers for comparison between them, or just use something generic like binja or ghidra.
Yeah - for now I'd lean towards "just slap objdump on it" (and call it objdump) as an easy and mostly-fine tradeoff? (Free for devs without binja licenses, and faster than ghidra)
On the other extreme, I did also prototype dumping out disassembly with decompilation line-number associations from Hex-Rays, displayed with godbolt style colouring of the disassembly and pseudocode, which might be possible with other tools too. (I think setting WITH_DISASM = True on line 5 of dump.py worked)
Currently if you have a dogbolt link where two tools disagree, there's no way to know which one is correct. (e.g. BinaryNinja vs Hex-Rays here)
Adding a "disassembly" pane would give a source of truth, to allow users to understand what the input to the decompilers actually was, and which one is correct.
The text was updated successfully, but these errors were encountered: