bugpoint - narzędzie do automatycznej redukcji przypadków testowych
bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args program arguments
bugpoint zawęża źródło problemów w narzędziach LLVM i przechodzi. Może być używany do debugowania trzech rodzajów awarii: awarii optymalizatora, błędów kompilacji przez optymalizatory lub złego generowania kodu natywnego (w tym problemów w kompilatorach statycznych i JIT). Ma na celu zredukowanie dużych przypadków testowych do małych, użytecznych. Aby uzyskać więcej informacji na temat projektu i wewnętrznego działania bugpoint, a także porady dotyczące używania punktu błędu, zobacz Narzędzie punktu błędu LLVM: projektowanie i użycie w dystrybucji LLVM.
Załaduj dynamiczny obiekt współdzielony bibliotekę do programu testowego za każdym razem, gdy jest uruchamiany. Jest to przydatne, jeśli debugujesz programy, których uruchamianie zależy od bibliotek innych niż LLVM (takich jak biblioteki X lub przekleństwa).
Dołącz kod zakończenia programów testowych do pliku wyjściowego, aby zmiana kodu zakończenia była uznawana za niepowodzenie testu. Domyślnie fałsz.
Przekaż wszystkie argumenty określone po --args do programu testowego przy każdym jego uruchomieniu. Pamiętaj, że jeśli którykolwiek z argumentów programu zaczyna się od „-”, powinieneś użyć:
bugpoint [bugpoint args] --args -- [program args]
„--” zaraz po opcji --args mówi bugpoint, aby rozważył wszystkie opcje zaczynające się od „- " być częścią opcji --args, a nie jako opcja samego błędu.
Przekaż wszystkie argumenty określone po --tool-args do testowanego narzędzia LLVM (llc, lli itd.) przy każdym jego uruchomieniu. Z opcji tej należy skorzystać w następujący sposób:
bugpoint [bugpoint args] --tool-args -- [tool args]
„--” zaraz po opcji --tool-args mówi bugpoint, aby rozważył wszystkie opcje zaczynające się od „-” jako część opcji --tool-args, a nie jako opcja samego błędu. (Patrz --args powyżej).
Przekaż wszystkie argumenty określone po --safe-tool-args do „bezpiecznego” narzędzia wykonawczego.
Przekaż wszystkie argumenty określone po --gcc-tool-args do wywołania gcc.
Przekaż wszystkie argumenty określone po --opt-args do wywołania opt.
Nie uruchamiaj określonych przebiegów w celu oczyszczenia i zmniejszenia rozmiaru programu testowego. Domyślnie bugpoint używa tych przebiegów wewnętrznie podczas próby zredukowania programów testowych. Jeśli próbujesz znaleźć błąd w jednym z tych przebiegów, bugpoint może ulec awarii.
Użyj valgrind, aby znaleźć błędy w fazie optymalizacji. Pozwoli to bugpointowi znaleźć bezobjawowe problemy spowodowane złym zarządzaniem pamięcią.
Nieustannie wybieraj losowo określone przebiegi i uruchamiaj je w programie testowym, dopóki nie zostanie znaleziony błąd lub użytkownik nie zabije błędu.
Wydrukuj podsumowanie opcji wiersza poleceń.
Otwórz plik nazwa_pliku i przekieruj standardowe wejście programu testowego za każdym razem, gdy jest uruchamiany, tak aby pochodziło z tego pliku.
Załaduj dynamiczny obiekt plugin do samego błędu. Ten obiekt powinien rejestrować nowe przebiegi optymalizacji. Po załadowaniu obiekt doda nowe opcje wiersza poleceń, aby umożliwić różne optymalizacje. Aby zobaczyć nową pełną listę optymalizacji, użyj razem opcji -help i --load; Na przykład:
bugpoint --load myNewPass.so -help
Określa górny limit użycia pamięci przez optymalizację i generator kodu. Ustaw na zero, aby wyłączyć limit.
Ilekroć program testowy generuje wyjście w swoim standardowym strumieniu wyjściowym, powinno ono pasować do zawartości nazwa pliku („wyjście referencyjne”). Jeśli nie użyjesz tej opcji, bugpoint spróbuje wygenerować referencyjne wyjście, kompilując program z „bezpiecznym” backendem i uruchamiając go.
Za każdym razem, gdy program testowy jest kompilowany, bugpoint powinien wygenerować dla niego kod przy użyciu określonego generatora kodu. Te opcje pozwalają wybrać odpowiednio interpreter, kompilator JIT, statyczny kompilator kodu natywnego lub polecenie niestandardowe (zobacz --exec-command).
Podczas debugowania generatora kodu bugpoint powinien używać określonego generatora kodu jako „bezpiecznego” generatora kodu. Jest to znany dobry generator kodu używany do generowania „wyjściowych danych wyjściowych”, jeśli nie zostały one dostarczone, oraz do kompilowania części programu, które są wykluczone z przypadku testowego. Te opcje pozwalają wybrać odpowiednio statyczny kompilator kodu natywnego lub polecenie niestandardowe (zobacz --exec-command). Interpreter i zaplecza JIT nie mogą obecnie być używane jako „bezpieczne” zaplecza.
Ta opcja definiuje polecenie używane z opcjami --run-custom i --safe-custom w celu wykonania przypadku testowego kodu bitowego. Może to być przydatne przy kompilacji krzyżowej.
Ta opcja definiuje polecenie używane z opcją --compile-custom w celu skompilowania przypadku testowego kodu bitowego. Polecenie powinno zakończyć się z kodem zakończenia błędu, jeśli plik jest „interesujący” i powinno zakończyć się z kodem wyjścia sukcesu (tj.
Może to być przydatne do testowania danych wyjściowych kompilatora bez uruchamiania jakichkolwiek etapów łączenia lub wykonywania. Aby wygenerować skrócony test jednostkowy, możesz dodać dyrektywy CHECK do przypadku testowego i przekazać nazwę wykonywalnego skryptu kompilacji w następującej postaci:
#!/bin/sh llc "$@" not FileCheck [bugpoint input file].ll < bugpoint-test-program.s
Ten skrypt „zawiedzie”, dopóki FileCheck przejdzie. Tak więc wynikiem będzie minimalny kod bitowy, który przejdzie FileCheck.
Ta opcja określa ścieżkę do polecenia, które ma zostać wykonane z opcją --safe-{int,jit,llc,custom}.
Domyślnym zachowaniem punktu błędu jest wypisanie „
Jeśli bugpoint odniesie sukces w znalezieniu problemu, zakończy działanie z wartością 0. W przeciwnym razie, jeśli wystąpi błąd, zakończy działanie z wartością różną od zera.
opt(1)
Utrzymywany przez zespół LLVM (https://llvm.org/).
2003-2023, Projekt LLVM