bugpoint - herramienta automática de reducción de casos de prueba
bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args program arguments
bugpoint reduce la fuente de problemas en las herramientas y pases de LLVM. Se puede usar para depurar tres tipos de fallas: bloqueos del optimizador, errores de compilación por parte de los optimizadores o mala generación de código nativo (incluidos problemas en los compiladores estáticos y JIT). Su objetivo es reducir los grandes casos de prueba a pequeños y útiles. Para obtener más información sobre el diseño y el funcionamiento interno de bugpoint, así como consejos para usar bugpoint, consulte Herramienta LLVM bugpoint: diseño y uso en la distribución de LLVM.
Cargue la biblioteca de objetos compartidos dinámicos en el programa de prueba siempre que se ejecute. Esto es útil si está depurando programas que dependen de bibliotecas que no son LLVM (como las bibliotecas X o curses) para ejecutarse.
Agregue el código de salida de los programas de prueba al archivo de salida para que un cambio en el código de salida se considere una falla de prueba. El valor predeterminado es falso.
Pase todos los argumentos especificados después de --args al programa de prueba siempre que se ejecute. Tenga en cuenta que si alguno de los argumentos del programa comienza con "-", debe usar:
bugpoint [bugpoint args] --args -- [program args]
El "--" justo después de la opción --args le dice a bugpoint que considere cualquier opción que comience con "- " para ser parte de la opción --args, no como opciones para bugpoint en sí mismo.
Pase todos los argumentos especificados después de --tool-args a la herramienta LLVM bajo prueba (llc, lli, etc.) siempre que se ejecute. Debe utilizar esta opción de la siguiente manera:
bugpoint [bugpoint args] --tool-args -- [tool args]
El "--" justo después de la opción --tool-args le dice a bugpoint que considere cualquier opción que comience con "-" para ser parte de la opción --tool-args, no como opciones para bugpoint en sí mismo. (Ver --args, arriba).
Pase todos los argumentos especificados después de --safe-tool-args a la herramienta de ejecución "segura".
Pase todos los argumentos especificados después de --gcc-tool-args a la invocación de gcc.
Pase todos los argumentos especificados después de --opt-args a la invocación de opt.
No ejecute los pases especificados para limpiar y reducir el tamaño del programa de prueba. De forma predeterminada, bugpoint usa estos pases internamente cuando intenta reducir los programas de prueba. Si está tratando de encontrar un error en uno de estos pases, bugpoint puede fallar.
Use valgrind para encontrar fallas en la fase de optimización. Esto permitirá que bugpoint encuentre problemas asintomáticos causados por una mala gestión de la memoria.
Aleatorice continuamente los pases especificados y ejecútelos en el programa de prueba hasta que se encuentre un error o el usuario elimine bugpoint.
Imprime un resumen de las opciones de la línea de comandos.
Abra nombre de archivo y redirija la entrada estándar del programa de prueba, siempre que se ejecute, para que provenga de ese archivo.
Cargue el objeto dinámico complemento en el propio bugpoint. Este objeto debería registrar nuevos pases de optimización. Una vez cargado, el objeto agregará nuevas opciones de línea de comando para habilitar varias optimizaciones. Para ver la nueva lista completa de optimizaciones, use las opciones -help y --load juntas; Por ejemplo:
bugpoint --load myNewPass.so -help
Especifica un límite superior en el uso de memoria de la optimización y la generación de código. Establézcalo en cero para deshabilitar el límite.
Siempre que el programa de prueba produzca una salida en su flujo de salida estándar, debe coincidir con el contenido de nombre de archivo (la "salida de referencia"). Si no usa esta opción, bugpoint intentará generar una salida de referencia compilando el programa con el backend "seguro" y ejecutándolo.
Cada vez que se compila el programa de prueba, bugpoint debe generar código para él utilizando el generador de código especificado. Estas opciones le permiten elegir el intérprete, el compilador JIT, el compilador de código nativo estático o un comando personalizado (consulte --exec-command) respectivamente.
Al depurar un generador de código, bugpoint debe usar el generador de código especificado como generador de código "seguro". Este es un generador de código conocido que se usa para generar la "salida de referencia" si no se ha proporcionado, y para compilar partes del programa que están excluidas del caso de prueba. Estas opciones le permiten elegir el compilador de código nativo estático o un comando personalizado (consulte --exec-command) respectivamente. El intérprete y los backends JIT no se pueden usar actualmente como backends "seguros".
Esta opción define el comando que se usará con las opciones --run-custom y --safe-custom para ejecutar el caso de prueba de código de bits. Esto puede ser útil para la compilación cruzada.
Esta opción define el comando que se usará con la opción --compile-custom para compilar el caso de prueba de código de bits. El comando debe salir con un código de salida de falla si el archivo es "interesante" y debe salir con un código de salida de éxito (es decir, 0) de lo contrario (esto es lo mismo que si fallara en las entradas "interesantes").
Esto puede ser útil para probar la salida del compilador sin ejecutar ningún enlace o ejecutar etapas. Para generar una prueba de unidad reducida, puede agregar directivas CHECK al caso de prueba y pasar el nombre de un script de comando de compilación ejecutable de esta forma:
#!/bin/sh llc "$@" not FileCheck [bugpoint input file].ll < bugpoint-test-program.s
Este script "fallará" siempre que FileCheck pase. Entonces, el resultado será el código de bits mínimo que pasa FileCheck.
Esta opción define la ruta al comando a ejecutar con la opción --safe-{int,jit,llc,custom}.
El comportamiento predeterminado de bugpoint es imprimir "
Si bugpoint logra encontrar un problema, saldrá con 0. De lo contrario, si ocurre un error, saldrá con un valor distinto de cero.
opt(1)
Mantenido por el equipo de LLVM (https://llvm.org/).
2003-2023, Proyecto LLVM