When LLM Decompilers Recompile More and Preserve Less
Decompilation recovers high-level source from compiled machine code and serves as a foundation for security tasks such as vulnerability detection and malware analysis. Traditional decompilers like Ghidra and Hex-Rays expose whatever they cannot resolve as visible placeholders and often emit pseudocode that will not compile or execute; LLM-based decompilers produce clean, idiomatic C and are now judged almost entirely by recompilability and re-executability: whether the output builds and passes its shipped input/output tests. We show that these metrics can reward the wrong path: a function may
Lineage graph
Paper → model → repo connections mined from source citations (Tier-1 exact match).
Why these links exist
Every edge carries a method, confidence, and the source snippet that justified it — so bad links are debuggable.
- PossiblePossibly related (embedding) · 52%MemoryOps AI: governed memory runtime for LLM agents with deletion-leakage evals and context admission [P] →
- FuzzyOverlapping authors or contributors · 62%modular/modular →
“Shared author/contributor keys: liu”
- LinkedLinked via arxiv author · 85%Chang Liu →
“When LLM Decompilers Recompile More and Preserve Less”
- LinkedLinked via arxiv author · 85%Edward Raff →
“When LLM Decompilers Recompile More and Preserve Less”
- LinkedLinked via arxiv author · 85%Kristopher Micinski →
“When LLM Decompilers Recompile More and Preserve Less”
