bugpoint - outil de réduction automatique des cas de test
bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args program arguments
bugpoint réduit la source des problèmes dans les outils LLVM et réussit. Il peut être utilisé pour déboguer trois types d'échecs : les plantages de l'optimiseur, les erreurs de compilation par les optimiseurs ou la mauvaise génération de code natif (y compris les problèmes dans les compilateurs statiques et JIT). Il vise à réduire les grands cas de test à de petits cas utiles. Pour plus d'informations sur la conception et le fonctionnement interne de bugpoint, ainsi que des conseils d'utilisation de bugpoint, consultez L'outil de point de bogue LLVM : conception et utilisation dans la distribution LLVM.
Chargez l'objet partagé dynamique bibliothèque dans le programme de test chaque fois qu'il est exécuté. Ceci est utile si vous déboguez des programmes qui dépendent de bibliothèques non LLVM (telles que les bibliothèques X ou curses) pour s'exécuter.
Ajoutez le code de sortie des programmes de test au fichier de sortie afin qu'une modification du code de sortie soit considérée comme un échec du test. La valeur par défaut est false.
Transmettez tous les arguments spécifiés après --args au programme de test à chaque exécution. Notez que si l'un des arguments du programme commence par "-", vous devez utiliser :
bugpoint [bugpoint args] --args -- [program args]
Le "--" juste après l'option --args indique à bugpoint de considérer toutes les options commençant par "- " pour faire partie de l'option --args, et non en tant qu'options pour bugpoint lui-même.
Transmettez tous les arguments spécifiés après --tool-args à l'outil LLVM testé (llc, lli, etc.) chaque fois qu'il s'exécute. Vous devez utiliser cette option de la manière suivante :
bugpoint [bugpoint args] --tool-args -- [tool args]
Le "--" juste après l'option --tool-args indique à bugpoint de considérer toutes les options commençant par "-" pour faire partie de l'option --tool-args, et non en tant qu'options pour bugpoint lui-même. (Voir --args, ci-dessus.)
Transmettez tous les arguments spécifiés après --safe-tool-args à l'outil d'exécution "sûr".
Passez tous les arguments spécifiés après --gcc-tool-args à l'invocation de gcc.
Passez tous les arguments spécifiés après --opt-args à l'invocation de opt.
N'exécutez pas les passes spécifiées pour nettoyer et réduire la taille du programme de test. Par défaut, bugpoint utilise ces passes en interne lorsqu'il tente de réduire les programmes de test. Si vous essayez de trouver un bogue dans l'une de ces passes, bugpoint peut planter.
Utilisez valgrind pour trouver des défauts dans la phase d'optimisation. Cela permettra à bugpoint de trouver des problèmes autrement asymptomatiques causés par une mauvaise gestion de la mémoire.
Randomisez continuellement les passes spécifiées et exécutez-les sur le programme de test jusqu'à ce qu'un bogue soit trouvé ou que l'utilisateur tue bugpoint.
Affiche un résumé des options de ligne de commande.
Ouvrez filename et redirigez l'entrée standard du programme de test, chaque fois qu'il s'exécute, pour qu'elle provienne de ce fichier.
Chargez l'objet dynamique plugin dans bugpoint lui-même. Cet objet doit enregistrer de nouvelles passes d'optimisation. Une fois chargé, l'objet ajoutera de nouvelles options de ligne de commande pour permettre diverses optimisations. Pour voir la nouvelle liste complète des optimisations, utilisez les options -help et --load ensemble ; Par exemple:
bugpoint --load myNewPass.so -help
Spécifie une limite supérieure d'utilisation de la mémoire pour l'optimisation et le codegen. Mettre à zéro pour désactiver la limite.
Chaque fois que le programme de test produit une sortie sur son flux de sortie standard, il doit correspondre au contenu de filename (la « sortie de référence »). Si vous n'utilisez pas cette option, bugpoint tentera de générer une sortie de référence en compilant le programme avec le backend "sûr" et en l'exécutant.
Chaque fois que le programme de test est compilé, bugpoint doit générer du code pour celui-ci en utilisant le générateur de code spécifié. Ces options vous permettent de choisir respectivement l'interpréteur, le compilateur JIT, le compilateur de code natif statique ou une commande personnalisée (voir --exec-command).
Lors du débogage d'un générateur de code, bugpoint doit utiliser le générateur de code spécifié comme générateur de code "sûr". Il s'agit d'un bon générateur de code connu utilisé pour générer la "sortie de référence" si elle n'a pas été fournie, et pour compiler des parties du programme qui sont exclues du cas de test. Ces options vous permettent de choisir respectivement le compilateur de code natif statique ou une commande personnalisée (voir --exec-command). L'interpréteur et les backends JIT ne peuvent actuellement pas être utilisés comme backends "sûrs".
Cette option définit la commande à utiliser avec les options --run-custom et --safe-custom pour exécuter le scénario de test du code binaire. Cela peut être utile pour la compilation croisée.
Cette option définit la commande à utiliser avec l'option --compile-custom pour compiler le cas de test du code binaire. La commande doit se terminer avec un code de sortie d'échec si le fichier est "intéressant" et doit se terminer avec un code de sortie de succès (c'est-à-dire 0) sinon (c'est la même chose que si elle plantait sur des entrées "intéressantes").
Cela peut être utile pour tester la sortie du compilateur sans exécuter de liens ni d'étapes d'exécution. Pour générer un test unitaire réduit, vous pouvez ajouter des directives CHECK au cas de test et transmettre le nom d'un script de commande de compilation exécutable sous cette forme :
#!/bin/sh llc "$@" not FileCheck [bugpoint input file].ll < bugpoint-test-program.s
Ce script "échouera" tant que FileCheck réussira. Ainsi, le résultat sera le bitcode minimum qui passe FileCheck.
Cette option définit le chemin vers la commande à exécuter avec l'option --safe-{int,jit,llc,custom}.
Le comportement par défaut de bugpoint est d'afficher "
Si bugpoint réussit à trouver un problème, il se terminera avec 0. Sinon, si une erreur se produit, il se terminera avec une valeur non nulle.
opt(1)
Maintenu par l'équipe LLVM (https://llvm.org/).
2003-2023, Projet LLVM