Newest papers

ExeBench-FHD: Addressing Fidelity Issues in Decompiler Evaluation

Akarsh Ashok, Dinil Mon Divakaran, Vivek Balachandran · 2026 · arXiv (Cornell University)

DOI: 10.48550/arxiv.2610.28212 · cited by 0 works (OpenAlex) · open-access PDF

Spanish

ExeBench es uno de los parámetros de datos más ampliamente utilizados para evaluar los descompiladores basados en LLM. Analizamos ExeBench e identificamos nueve problemas que afectan a la fiabilidad de una prueba que mide un descompilador. Tres de ellos impiden que los descompiladores de LLM recuperen el código C de la función de ExeBench. Estos son el orden de parámetros ambiguo en el optimizador cuando se mezclan los tipos de puntos enteros y flotantes, los parámetros no utilizados que el ensamblaje optimizado puede caer, y las constantes almacenadas fuera del código de ensamblaje de la función. Seis más afectan a la validez de la prueba: las funciones no vacías sin un retorno, los tipos de poseedor de lugar, las funciones está

Machine translation (Meta M2M100); the English original follows.

Abstract

ExeBench is one of the most widely used benchmarks for evaluating LLM-based decompilers. We analyze ExeBench and identify nine issues that affect how faithfully a test measures a decompiler. Three of them prevent LLM decompilers from recovering C code from ExeBench's function. These are ambiguous parameter order when integer and floating-point types are mixed, unused parameters that optimized assembly may drop, and constants stored outside the function's assembly code. Six more affect test validity: non-void functions without a return, placeholder types, static or inline functions removed by the optimizer, functions named main, trivial bodies and truncated definitions. We present ExeBench-FHD, a backward-compatible revision of ExeBench that adds 16 new fields: call-site assembly, data sections, test wrappers, linked-binary disassembly and five warning flags. In ExeBench, 38.9% of functions have at least one of the five flags; dropping records with any of the four warning flags (all except unused_param, which marks functions that the new wrappers make evaluable) keeps 63.9% of the corpus. In an evaluation at -O2 on four architectures, the new fields raise GPT 6 Sol's re-execution rate by up to 26.5%, 19.1% and 21.0% on functions that read data sections, mix parameter types and have unused parameters, respectively.

Read in: English · Spanish · Chinese · Hindi · Arabic · Portuguese · French · German · Japanese · Russian · Korean · Indonesian · Vietnamese

Topics: Computer science, Fidelity, Code (set theory), Test (biology), Integer (computer science), Order (exchange)

Sources: OpenAlex (CC0), arXiv, Crossref. Agent Exchange