bugpoint - инструмент автоматического сокращения тестовых случаев
bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args program arguments
bugpoint сужает источник проблем в инструментах и пропусках LLVM. Его можно использовать для отладки трех типов сбоев: сбои оптимизатора, неправильная компиляция оптимизаторами или неправильное создание собственного кода (включая проблемы в статических и JIT-компиляторах). Он направлен на сокращение больших тестовых случаев до небольших, полезных. Для получения дополнительной информации о дизайне и внутренней работе bugpoint, а также советов по использованию bugpoint, см. инструмент LLVM bugpoint: дизайн и использование в дистрибутиве LLVM.
Загружайте библиотеку динамических общих объектов в тестовую программу всякий раз, когда она запускается. Это полезно, если вы отлаживаете программы, запуск которых зависит от библиотек, отличных от LLVM (таких как библиотеки X или curses).
Добавьте код выхода тестовых программ в выходной файл, чтобы изменение кода выхода считалось ошибкой теста. По умолчанию ложно.
Передайте все аргументы, указанные после --args, тестовой программе при ее запуске. Обратите внимание, что если какой-либо из аргументов программы начинается с "-", вы должны использовать:
bugpoint [bugpoint args] --args -- [program args]
"--" сразу после параметра ---args указывает bugpoint рассматривать любые варианты, начинающиеся с "- " быть частью опции --args, а не как опции bugpoint.
Передайте все аргументы, указанные после --tool-args, тестируемому инструменту LLVM (llc, lli и т. д.) при каждом его запуске. Вы должны использовать эту опцию следующим образом:
bugpoint [bugpoint args] --tool-args -- [tool args]
"--" сразу после параметра --tool-args указывает bugpoint рассматривать любые варианты, начинающиеся с "-" как часть параметра --tool-args, а не как параметры самой ошибки. (См. --args выше.)
Передайте все аргументы, указанные после --safe-tool-args, "безопасному" инструменту выполнения.
Передайте все аргументы, указанные после --gcc-tool-args, в вызов gcc.
Передайте все аргументы, указанные после --opt-args, в вызов opt.
Не запускайте указанные проходы для очистки и уменьшения размера тестовой программы. По умолчанию bugpoint использует эти проходы внутри себя при попытке сократить тестовые программы. Если вы пытаетесь найти ошибку в одном из этих проходов, может произойти сбой bugpoint.
Используйте valgrind для поиска ошибок на этапе оптимизации. Это позволит выявить бессимптомные проблемы, вызванные неправильным управлением памятью.
Постоянно рандомизируйте указанные проходы и запускайте их в тестовой программе, пока не будет найдена ошибка или пользователь не устранит точку ошибки.
Распечатайте сводку параметров командной строки.
Откройте имя_файла и перенаправьте стандартный ввод тестовой программы всякий раз, когда она запускается, чтобы он поступал из этого файла.
Загрузите динамический объект plugin в сам bugpoint. Этот объект должен регистрировать новые проходы оптимизации. После загрузки объект добавит новые параметры командной строки для включения различных оптимизаций. Чтобы увидеть новый полный список оптимизаций, используйте вместе параметры -help и --load; например:
bugpoint --load myNewPass.so -help
Указывает верхний предел использования памяти оптимизацией и codegen. Установите на ноль, чтобы отключить ограничение.
Всякий раз, когда тестовая программа производит вывод в своем стандартном потоке вывода, он должен совпадать с содержимым имя файла ("эталонный вывод"). Если вы не используете эту опцию, bugpoint попытается сгенерировать эталонный вывод, скомпилировав программу с "безопасным" бэкендом и запустив ее.
Всякий раз, когда тестовая программа компилируется, bugpoint должен генерировать для нее код с помощью указанного генератора кода. Эти параметры позволяют выбрать интерпретатор, JIT-компилятор, статический компилятор собственного кода или пользовательскую команду (см. --exec-command) соответственно.
При отладке генератора кода bugpoint должен использовать указанный генератор кода в качестве "безопасного" генератора кода. Это хорошо зарекомендовавший себя генератор кода, используемый для создания «справочного вывода», если он не был предоставлен, и для компиляции частей программы, которые исключаются из тестового примера. Эти параметры позволяют выбрать компилятор статического собственного кода или пользовательскую команду (см. --exec-command) соответственно. Интерпретатор и серверные части JIT в настоящее время нельзя использовать в качестве «безопасных» серверных частей.
Этот параметр определяет команду, которую следует использовать с параметрами --run-custom и --safe-custom для выполнения тестового примера битового кода. Это может быть полезно для кросс-компиляции.
Этот параметр определяет команду, которую следует использовать с параметром --compile-custom для компиляции тестового примера битового кода. Команда должна завершаться с кодом выхода с ошибкой, если файл «интересный», и должна завершаться с кодом успешного выхода (т. е. 0) в противном случае (это то же самое, как если бы она аварийно завершала работу на «интересных» входных данных).
Это может быть полезно для тестирования вывода компилятора без запуска каких-либо стадий компоновки или выполнения. Чтобы сгенерировать сокращенный модульный тест, вы можете добавить директивы CHECK в тестовый пример и передать имя исполняемого скрипта команды компиляции в этой форме:
#!/bin/sh llc "$@" not FileCheck [bugpoint input file].ll < bugpoint-test-program.s
Этот сценарий будет «терпеть неудачу», пока проходит FileCheck. Таким образом, результатом будет минимальный биткод, который проходит FileCheck.
Этот параметр определяет путь к команде для выполнения с параметром --safe-{int,jit,llc,custom}.
По умолчанию bugpoint выводит «
Если bugpoint удается найти проблему, он завершается с 0. В противном случае, если возникает ошибка, он завершается с ненулевым значением.
opt(1)
Поддерживается командой LLVM (https://llvm.org/).
2003-2023, проект LLVM