ccc
v2.1
Una biblioteca y un conjunto de herramientas de línea de comandos para analizar símbolos de depuración de juegos de PS2. La serie de versiones 1.x se centró en los símbolos STABS en las secciones .mdebug, mientras que la serie de versiones 2.x también puede analizar símbolos ELF estándar y símbolos enlazadores SNDLL. El soporte de DWARF está en proceso.
Demangler de símbolos C++ compatible tanto con el nuevo esquema de manipulación Itanium C++ ABI (GCC 3+) como con el antiguo esquema GCC 2.
Desmontador MIPS de núcleo EE a medio trabajo. Probablemente no sea demasiado interesante.
Analizador y volcador de tablas de símbolos. Puede extraer la siguiente información:
Se admiten los siguientes formatos de salida:
Esto está pensado para usarse con ghidra-emotionengine-reloaded (>= 2.1.0 o una de las compilaciones inestables) para importar toda esta información a Ghidra. Tenga en cuenta que a pesar del nombre, el analizador STABS debería funcionar para el R3000 (IOP) y posiblemente también para otros procesadores MIPS.
Esto es similar a stdump excepto que organiza su salida en archivos fuente separados y tiene una serie de características adicionales diseñadas para intentar acercar dicha salida al código fuente válido. Se debe proporcionar un archivo SOURCES.txt en el directorio de salida, que se puede generar usando el comando stdump files (debe arreglar las rutas manualmente para que sean relativas al directorio de salida y eliminar las direcciones). Además, los archivos que no estén vacíos y que no comiencen con // STATUS: NOT STARTED no se sobrescribirán.
Si se proporciona un archivo FUNCTIONS.txt en el directorio de salida, como se puede generar usando el script CCCDecompileAllFunctions.java incluido para Ghidra, el código de ese archivo se usará para completar los cuerpos de las funciones en la salida. En este caso, el primer grupo de declaraciones de variables locales emitidas serán las recuperadas de los símbolos, y el segundo grupo será el código proporcionado en el archivo de funciones. Los nombres de las funciones están demandados.
Los datos de las variables globales se imprimirán de forma estructurada según su tipo de datos.
Los tipos de datos se ordenarán en sus archivos correspondientes. Dado que esta información no se almacena en la tabla de símbolos, uncc utiliza heurísticas para asignar tipos a archivos. Los tipos se colocarán en archivos .c o .cpp cuando solo haya una unidad de traducción en la que aparezca el tipo, y en archivos .h cuando haya varias (y, por lo tanto, cuando se deban usar heurísticas para determinar dónde colocarlos).
Se recomienda el uso de un formateador de código como clang-format o astyle en la salida.
cmake -B bin/
cmake --build bin/
mdebugread.c de gdb (lectura)ecoff.c de gas (escritura)include/coff/sym.h de binutils (encabezados)stabs.c de binutils (lectura)stabsread.c de gdb (lectura)dbxread.c de gdb (lectura)dbxout.c de gcc (escritura)stab.def de gcc (códigos de símbolos) El código fuente de la biblioteca CCC y las herramientas de línea de comandos asociadas se publica bajo la licencia MIT.
Se utiliza el demangler GNU, que contiene archivos fuente con licencia GPL y LGPL. RapidJSON se utiliza bajo la licencia MIT. El conjunto de pruebas utiliza la biblioteca GoogleTest bajo la licencia BSD de 3 cláusulas.
