valgrind - En ligne dans le Cloud

PROGRAMME:

Nom

valgrind - une suite d'outils pour le débogage et le profilage des programmes

SYNOPSIS

valgrind [options-valgrind] [votre-programme] [vos-options-de-programme]

DESCRIPTION

Valgrind est un programme flexible pour le débogage et le profilage des exécutables Linux. Il consiste
d'un noyau, qui fournit un processeur synthétique dans le logiciel, et une série de débogage et
outils de profilage. L'architecture est modulaire, de sorte que de nouveaux outils peuvent être créés facilement et
sans perturber la structure existante.

Certaines des options décrites ci-dessous fonctionnent avec tous les outils Valgrind, et certaines ne fonctionnent qu'avec
quelques-uns ou un. La section OPTIONS MEMCHECK et celles en dessous décrivent des outils spécifiques
options.

Cette page de manuel ne couvre que l'utilisation et les options de base. Pour des informations plus complètes,
veuillez consulter la documentation HTML sur votre système :
$INSTALL/share/doc/valgrind/html/index.html, ou en ligne :
http://www.valgrind.org/docs/manual/index.html.

OUTIL SÉLECTION OPTIONS

L'option la plus importante.

--outil= [défaut: vérification de la mémoire]
Exécutez l'outil Valgrind appelé nom de l'outil, par exemple memcheck, cachegrind, callgrind, helgrind,
drd, massif, laquais, aucun, exp-sgcheck, exp-bbv, exp-dhat, etc.

BASIQUE OPTIONS

Ces options fonctionnent avec tous les outils.

-h --Aidez-moi
Affiche l'aide pour toutes les options, à la fois pour le noyau et pour l'outil sélectionné. Si l'option
est répété cela équivaut à donner --help-débogage.

--help-débogage
Pareil que --Aidez-moi, mais répertorie également les options de débogage qui ne sont généralement utiles que pour
Les développeurs de Valgrind.

--version
Affiche le numéro de version du noyau Valgrind. Les outils peuvent avoir leur propre version
Nombres. Un système est en place pour garantir que les outils ne s'exécutent que lorsque le noyau
est une version avec laquelle ils sont connus pour travailler. Cela a été fait pour minimiser les risques de
d'étranges problèmes résultant d'incompatibilités entre la version outil et la version core.

-q, --silencieux
Exécutez silencieusement et imprimez uniquement les messages d'erreur. Utile si vous exécutez une régression
tests ou avoir d'autres machines de test automatisées.

-v, --verbeux
Soyez plus bavard. Fournit des informations supplémentaires sur divers aspects de votre programme, tels que :
les objets partagés chargés, les suppressions utilisées, l'avancement de l'instrumentation
et moteurs d'exécution, ainsi que des avertissements concernant les comportements inhabituels. Répéter l'option
augmente le niveau de verbosité.

--trace-enfants= [défaut: non]
Lorsqu'il est activé, Valgrind tracera dans les sous-processus initiés via le exec Système
appel. Ceci est nécessaire pour les programmes multi-processus.

Notez que Valgrind remonte à l'enfant d'un fourche (il serait difficile de ne pas le faire,
depuis fourche fait une copie identique d'un processus), donc cette option est sans doute mal
nommé. Cependant, la plupart des enfants de fourche appelle appelez immédiatement exec de toute façon.

--trace-children-skip=patt1,patt2,...
Cette option n'a d'effet que lorsque --trace-enfants=oui est spécifié. Il permet de
certains enfants à sauter. L'option prend une liste de modèles séparés par des virgules pour
les noms des exécutables enfants dans lesquels Valgrind ne doit pas tracer. Les motifs peuvent
inclure les métacaractères ? et *, qui ont le sens habituel.

Cela peut être utile pour élaguer les branches inintéressantes d'un arbre de processus en cours
courir sur Valgrind. Mais vous devez être prudent lorsque vous l'utilisez. Quand Valgrind saute le traçage
dans un exécutable, il ne saute pas seulement le traçage de cet exécutable, il saute également
traçage de l'un des processus enfants de cet exécutable. En d'autres termes, le drapeau ne
provoque simplement l'arrêt du traçage aux exécutables spécifiés - il ignore le traçage de
des sous-arbres de processus entiers enracinés dans l'un des exécutables spécifiés.

--trace-children-skip-by-arg=patt1,patt2,...
C'est la même chose que --trace-enfants-skip, avec une différence : la décision de
s'il faut tracer un processus enfant en examinant les arguments à l'enfant
processus, plutôt que le nom de son exécutable.

--child-silent-after-fork= [défaut: non]
Lorsqu'il est activé, Valgrind n'affichera aucune sortie de débogage ou de journalisation pour l'enfant
processus résultant d'une fourche appel. Cela peut rendre la sortie moins confuse (bien que
plus trompeuse) lorsqu'il s'agit de processus qui créent des enfants. C'est particulièrement
utile en conjonction avec --trace-enfants=. L'utilisation de cette option est également fortement
recommandé si vous demandez une sortie XML (--xml=oui), car sinon le XML de
l'enfant et le parent peuvent se confondre, ce qui le rend généralement inutile.

--vgdb= [défaut: Oui]
Valgrind fournira la fonctionnalité "gdbserver" lorsque --vgdb=oui or --vgdb=complet is
spécifié. Cela permet à un débogueur GNU GDB externe de contrôler et de déboguer votre programme
quand il fonctionne sur Valgrind. --vgdb=complet entraîne des frais généraux de performance importants, mais
fournit des points d'arrêt et des points de surveillance plus précis. Voir Déboguer votre programme en utilisant
gdbserver et GDB de Valgrind pour une description détaillée.

Si le gdbserver intégré est activé mais qu'aucun gdb n'est actuellement utilisé, le vgdb
L'utilitaire de ligne de commande peut envoyer des "commandes de surveillance" à Valgrind à partir d'un shell. Les
Le noyau Valgrind fournit un ensemble de commandes de moniteur Valgrind. Un outil peut éventuellement
fournir des commandes de moniteur spécifiques à l'outil, qui sont documentées dans le document spécifique à l'outil
chapitre.

--vgdb-erreur= [défaut: 999999999]
Utilisez cette option lorsque le gdbserver Valgrind est activé avec --vgdb=oui or --vgdb=complet.
Les outils qui signalent des erreurs attendront que le "nombre" d'erreurs soit signalé avant de geler
le programme et attend que vous vous connectiez à GDB. Il s'ensuit qu'une valeur de zéro
provoquera le démarrage de gdbserver avant l'exécution de votre programme. C'est
généralement utilisé pour insérer des points d'arrêt GDB avant l'exécution, et fonctionne également avec des outils
qui ne rapportent pas d'erreurs, comme Massif.

--vgdb-stop-at= [défaut: rien]
Utilisez cette option lorsque le gdbserver Valgrind est activé avec --vgdb=oui or --vgdb=complet.
Le Valgrind gdbserver sera invoqué pour chaque erreur après --vgdb-erreur sont considérés
signalé. Vous pouvez également demander au serveur gdb de Valgrind d'être invoqué pour d'autres
événements, spécifiés de l'une des manières suivantes :

· une liste séparée par des virgules d'un ou plusieurs de Commencez sortie valgrindabexit.

Les valeurs Commencez sortie valgrindabexit indiquent respectivement d'invoquer gdbserver
avant l'exécution de votre programme, après la dernière instruction de votre programme, sur
Sortie anormale de Valgrind (par exemple erreur interne, manque de mémoire, ...).

Attention: Commencez et --vgdb-erreur=0 les deux provoqueront l'appel de Valgrind gdbserver
avant l'exécution de votre programme. Les --vgdb-erreur=0 entraînera en outre votre
programme pour s'arrêter sur toutes les erreurs suivantes.

· tous pour spécifier l'ensemble complet. C'est équivalent à
--vgdb-stop-at=démarrage,sortie,valgrindabexit.

· aucun pour l'ensemble vide.

--track-fds= [défaut: non]
Lorsqu'il est activé, Valgrind imprimera une liste des descripteurs de fichiers ouverts à la sortie ou sur
requête, via la commande gdbserver monitor v.info ouvert_fds. Avec chaque fichier
le descripteur est imprimé une trace de pile de l'endroit où le fichier a été ouvert et tous les détails
relatif au descripteur de fichier tel que le nom du fichier ou les détails du socket.

--horodatage= [défaut: non]
Lorsqu'il est activé, chaque message est précédé d'une indication de l'horloge murale écoulée
temps écoulé depuis le démarrage, exprimé en jours, heures, minutes, secondes et millisecondes.

--log-fd= [défaut: 2, stderr]
Spécifie que Valgrind doit envoyer tous ses messages au fichier spécifié
descripteur. La valeur par défaut, 2, est le canal d'erreur standard (stderr). Notez que cela peut
interférer avec l'utilisation de stderr par le client, car la sortie de Valgrind sera
entrelacé avec toute sortie que le client envoie à stderr.

--log-file=
Spécifie que Valgrind doit envoyer tous ses messages au fichier spécifié. Si la
le nom du fichier est vide, cela provoque un abandon. Il existe trois spécificateurs de format spéciaux qui
peut être utilisé dans le nom du fichier.

%p est remplacé par l'ID de processus actuel. Ceci est très utile pour le programme qui
invoquer plusieurs processus. AVERTISSEMENT : si vous utilisez --trace-enfants=oui et votre programme
invoque plusieurs processus OU votre programme bifurque sans appeler exec par la suite, et
vous n'utilisez pas ce spécificateur (ou le %q spécificateur ci-dessous), la sortie Valgrind de tous
ces processus seront regroupés dans un seul fichier, éventuellement brouillés et éventuellement incomplets.

%q{FOO} est remplacé par le contenu de la variable d'environnement FOO. Si l' {FOO}
la pièce est malformée, cela provoque un avortement. Ce spécificateur est rarement nécessaire, mais très
utile dans certaines circonstances (par exemple lors de l'exécution de programmes MPI). L'idée est que vous
spécifier une variable qui sera définie différemment pour chaque processus du travail, par exemple
exemple BPROC_RANK ou tout ce qui est applicable dans votre configuration MPI. Si le nommé
La variable d'environnement n'est pas définie, cela provoque un abandon. Notez que dans certains shells, le {
et } les caractères peuvent avoir besoin d'être échappés avec une barre oblique inverse.

%% est remplacé par %.

Si une % est suivi de tout autre caractère, cela provoque un abandon.

Si le nom de fichier spécifie un nom de fichier relatif, il est mis dans le premier
répertoire de travail : c'est le répertoire courant lorsque le programme a démarré son
exécution après le fork ou après l'exec. S'il spécifie un nom de fichier absolu (c'est-à-dire.
commence par '/') puis il est mis là.

--log-socket=
Spécifie que Valgrind doit envoyer tous ses messages au port spécifié au
adresse IP spécifiée. Le port peut être omis, auquel cas le port 1500 est utilisé. Si un
la connexion ne peut pas être établie sur le socket spécifié, Valgrind revient à l'écriture
sortie à l'erreur standard (stderr). Cette option est destinée à être utilisée dans
en conjonction avec le programme valgrind-listener. Pour plus de détails, voir le
commentaire dans le manuel.

LIÉ À UNE ERREUR OPTIONS

Ces options sont utilisées par tous les outils qui peuvent signaler des erreurs, par exemple Memcheck, mais pas
Cachegrind.

--xml= [défaut: non]
Lorsqu'elle est activée, les parties importantes de la sortie (par exemple les messages d'erreur d'outil) seront dans
Format XML plutôt que texte brut. De plus, la sortie XML sera envoyée à un
canal de sortie différent de celui de la sortie en texte brut. Par conséquent, vous devez également utiliser un
of --xml-fd, --xml-fichier or --xml-socket pour spécifier où le XML doit être envoyé.

Les messages moins importants seront toujours imprimés en texte brut, mais parce que le XML
la sortie et la sortie en texte brut sont envoyées à différents canaux de sortie (la destination de
la sortie en texte brut est toujours contrôlée par --log-fd, --fichier journal et --log-socket)
cela ne devrait pas poser de problèmes.

Cette option vise à faciliter la vie des outils qui consomment la production de Valgrind comme
d'entrée, telles que les interfaces graphiques frontales. Actuellement, cette option fonctionne avec Memcheck, Helgrind,
DRD et SGcheck. Le format de sortie est spécifié dans le fichier
docs/internals/xml-output-protocol4.txt dans l'arborescence des sources pour Valgrind 3.5.0 ou
plus tard.

Les options recommandées pour qu'une interface graphique passe, lors d'une demande de sortie XML, sont : --xml=oui
pour activer la sortie XML, --xml-fichier pour envoyer la sortie XML à un (probablement sélectionné par l'interface graphique)
fichier, --fichier journal pour envoyer la sortie en texte brut à un deuxième fichier sélectionné par l'interface graphique,
--child-silent-after-fork=oui et -q pour restreindre la sortie de texte brut à critique
messages d'erreur créés par Valgrind lui-même. Par exemple, l'échec de la lecture d'un
suppressions compte comme un message d'erreur critique. Ainsi, pour une réussite
exécuter le fichier de sortie de texte sera vide. Mais s'il n'est pas vide, il contiendra
informations importantes dont l'utilisateur de l'interface graphique doit être informé.

--xml-fd= [défaut: -1, désactivée]
Spécifie que Valgrind doit envoyer sa sortie XML au descripteur de fichier spécifié.
Il doit être utilisé en conjonction avec --xml=oui.

--xml-file=
Spécifie que Valgrind doit envoyer sa sortie XML au fichier spécifié. Ce doit être
utilisé en conjonction avec --xml=oui. Tout %p or %q séquences apparaissant dans le nom de fichier
sont étendus exactement de la même manière que pour --fichier journal. Voir le descriptif
of --fichier journal pour en savoir plus.

--xml-socket=
Spécifie que Valgrind doit envoyer sa sortie XML au port spécifié au
Adresse IP. Il doit être utilisé en conjonction avec --xml=oui. La forme de l'argument est
le même que celui utilisé par --log-socket. Voir la description de --log-socket Pour de plus amples
détails.

--xml-user-comment=
Incorpore une chaîne de commentaire utilisateur supplémentaire au début de la sortie XML. Ne fonctionne que lorsque
--xml=oui est spécifié; ignoré autrement.

--demangle= [défaut: Oui]
Activer/désactiver le démembrement (décodage) automatique des noms C++. Activé par défaut. Lorsque
activé, Valgrind tentera de traduire les noms C++ codés en quelque chose
se rapprochant de l'original. Le demangler gère les symboles mutilés par les versions g++ 2.X,
3.X et 4.X.

Un fait important à propos du démembrement est que les noms de fonction mentionnés dans les suppressions
les fichiers doivent être dans leur forme mutilée. Valgrind ne démêle pas les noms de fonction lorsque
rechercher les suppressions applicables, car faire autrement rendrait la suppression
contenu du fichier dépendant de l'état des machines de démêlage de Valgrind, et aussi lent
correspondance de suppression vers le bas.

--num-appelants= [défaut: 12]
Spécifie le nombre maximum d'entrées affichées dans les traces de pile qui identifient le programme
Emplacements. Notez que les erreurs sont communes en utilisant uniquement les quatre premiers emplacements de fonction
(la place dans la fonction courante, et celle de ses trois appelants immédiats). Donc ça
n'affecte pas le nombre total d'erreurs signalées.

La valeur maximale pour cela est de 500. Notez que des paramètres plus élevés obligeront Valgrind à exécuter un
un peu plus lentement et prend un peu plus de mémoire, mais peut être utile lorsque vous travaillez avec
programmes avec des chaînes d'appel profondément imbriquées.

--unw-stack-scan-thresh= [défaut: 0] , --unw-stack-scan-frames= [défaut:
5]
La prise en charge de l'analyse de la pile n'est disponible que sur les cibles ARM.

Ces indicateurs activent et contrôlent le déroulement de la pile par balayage de la pile. Quand la normale
mécanismes de déroulement de la pile -- utilisation des enregistrements Dwarf CFI et suivi du pointeur de trame
-- échoue, l'analyse de la pile peut être en mesure de récupérer une trace de la pile.

Notez que l'analyse de la pile est un mécanisme heuristique imprécis qui peut donner très
résultats trompeurs, voire aucun. Il ne doit être utilisé qu'en cas d'urgence, lorsqu'il est normal
le déroulement échoue, et il est important d'avoir néanmoins des traces de pile.

Le balayage de pile est une technique simple : le dérouleur lit les mots de la pile et
essaie de deviner laquelle d'entre elles pourrait être des adresses de retour, en vérifiant si elles
pointez juste après les instructions d'appel ARM ou Thumb. Si c'est le cas, le mot est ajouté à la
retour en arrière.

Le principal danger survient lorsqu'un appel de fonction revient, laissant son adresse de retour
exposé, et une nouvelle fonction est appelée, mais la nouvelle fonction n'écrase pas l'ancienne
adresse. Le résultat de ceci est que le backtrace peut contenir des entrées pour les fonctions
qui sont déjà revenus, et donc être très déroutant.

Une deuxième limitation de cette implémentation est qu'elle ne numérisera que la page (4 Ko,
normalement) contenant le pointeur de pile de départ. Si les cadres de pile sont grands, cela
peut entraîner la présence de quelques-uns seulement (voire aucun) dans la trace. Aussi, si vous
sont malchanceux et ont un pointeur de pile initial vers la fin de sa page contenant, le
le scan peut manquer toutes les images intéressantes.

Par défaut, l'analyse de la pile est désactivée. Le cas d'utilisation normal est de le demander lorsqu'un
la trace de la pile serait sinon très courte. Donc, pour l'activer, utilisez
--unw-stack-scan-thresh=nombre. Cela demande à Valgrind d'essayer d'utiliser l'analyse de la pile pour
« étendre » les traces de pile qui contiennent moins de cadres numériques.

Si la numérisation de la pile a lieu, elle ne générera au plus que le nombre d'images
spécifié par --unw-stack-scan-frames. En règle générale, l'analyse de la pile génère tellement de
garbage entrées que cette valeur est définie sur une valeur faible (5) par défaut. En aucun cas
une trace de pile supérieure à la valeur spécifiée par --num-callers soit créée.

--error-limit= [défaut: Oui]
Lorsqu'il est activé, Valgrind arrête de signaler les erreurs après 10,000,000 1,000 XNUMX au total, ou XNUMX XNUMX
différents, ont été vus. Il s'agit d'arrêter la machine de suivi des erreurs de
devenant un énorme surcoût de performances dans les programmes avec de nombreuses erreurs.

--error-exitcode= [défaut: 0]
Spécifie un code de sortie alternatif à retourner si Valgrind a signalé des erreurs dans le
Cours. Lorsqu'elle est définie sur la valeur par défaut (zéro), la valeur de retour de Valgrind sera toujours
être la valeur de retour du processus simulé. Lorsqu'il est défini sur une valeur non nulle, ce
valeur est renvoyée à la place, si Valgrind détecte des erreurs. Ceci est utile pour utiliser
Valgrind dans le cadre d'une suite de tests automatisés, car il facilite la détection des tests
cas pour lesquels Valgrind a signalé des erreurs, simplement en inspectant les codes de retour.

--error-markers= , [défaut: rien]
Lorsque les erreurs sont affichées en texte brut (c'est-à-dire XML non utilisé), --marqueurs d'erreur charge de
afficher une ligne contenant le commencer (fin) chaîne avant (après) chaque erreur.

De telles lignes de repère facilitent la recherche d'erreurs et/ou l'extraction d'erreurs dans un
fichier de sortie contenant des erreurs valgrind mélangées à la sortie du programme.

Notez que les marqueurs vides sont acceptés. Ainsi, seul l'utilisation d'un marqueur de début (ou de fin) est
de qualité.

--sigill-diagnostics= [défaut: Oui]
Activer/désactiver l'impression des diagnostics d'instructions illégales. Activé par défaut, mais
est désactivé par défaut lorsque --silencieux est donné. La valeur par défaut peut toujours être explicitement
outrepassé en donnant cette option.

Lorsqu'il est activé, un message d'avertissement sera imprimé, avec quelques diagnostics, chaque fois que
une instruction est rencontrée que Valgrind ne peut pas décoder ou traduire, avant le
programme reçoit un signal SIGILL. Souvent, une instruction illégale indique un bogue dans le
programme ou support manquant pour l'instruction particulière dans Valgrind. Mais quelques
programmes essaient délibérément d'exécuter une instruction qui pourrait être manquante et piège
le signal SIGILL pour détecter les caractéristiques du processeur. L'utilisation de ce drapeau permet de
évitez la sortie de diagnostic que vous obtiendriez autrement dans de tels cas.

--show-below-main= [défaut: non]
Par défaut, les traces de pile pour les erreurs n'affichent aucune fonction qui apparaît en dessous principal
parce que la plupart du temps, il s'agit de trucs de bibliothèque C inintéressants et/ou de charabia.
Sinon, si principal n'est pas présent dans la trace de la pile, les traces de la pile ne s'afficheront pas
toutes les fonctions ci-dessous principal-comme des fonctions telles que la glibc __libc_start_main.
En outre, si principal-comme des fonctions sont présentes dans la trace, elles sont normalisées comme
(au dessous de principale), afin de rendre la sortie plus déterministe.

Si cette option est activée, toutes les entrées de trace de pile seront affichées et principal-Comme
les fonctions ne seront pas normalisées.

--fullpath-after= [défaut: ne le font pas montrer source chemins]
Par défaut, Valgrind n'affiche que les noms de fichiers dans les traces de pile, mais pas les chemins complets vers
fichiers source. Lors de l'utilisation de Valgrind dans de grands projets où les sources résident dans
plusieurs répertoires différents, cela peut être gênant. --fullpath-après fournit une
solution flexible à ce problème. Lorsque cette option est présente, le chemin d'accès à chaque
le fichier source est affiché, avec la mise en garde suivante : si un magnifique se trouve dans
le chemin, puis le chemin jusqu'à et y compris un magnifique est omis, sinon le chemin est affiché
non modifié. Noter que un magnifique ne doit pas nécessairement être un préfixe du chemin.

Par exemple, considérons un fichier nommé /home/janedoe/blah/src/foo/bar/xyzzy.c. En précisant
--fullpath-after=/home/janedoe/blah/src/ fera que Valgrind affichera le nom comme
foo/bar/xyzzy.c.

Étant donné que la chaîne ne doit pas nécessairement être un préfixe, --fullpath-after=src/ produira
la même sortie. Ceci est utile lorsque le chemin contient arbitrairement généré par la machine
personnages. Par exemple, le chemin /my/build/dir/C32A1B47/blah/src/foo/xyzzy peut être
élagué à foo/xyzzy en utilisant --fullpath-after=/blah/src/.

Si vous voulez simplement voir le chemin complet, spécifiez simplement une chaîne vide :
--fullpath-after=. Il ne s'agit pas d'un cas particulier, mais simplement d'une conséquence logique de la
règles ci-dessus.

Enfin, vous pouvez utiliser --fullpath-après plusieurs fois. Toute apparition de celui-ci provoque
Valgrind pour passer à la production de chemins complets et à l'application de la règle de filtrage ci-dessus. Chaque
chemin produit est comparé à tous les --fullpath-après-chaînes spécifiées, dans le
ordre spécifié. La première chaîne à correspondre entraîne la troncation du chemin en tant que
décrit ci-dessus. Si aucune ne correspond, le chemin complet est affiché. Cela facilite le découpage
préfixes lorsque les sources sont tirées d'un certain nombre de répertoires non liés.

--extra-debuginfo-path= [défaut: indéfini et inutilisé]
Par défaut, Valgrind recherche dans plusieurs chemins bien connus des objets de débogage, tels que
/usr/lib/debug/.

Cependant, il peut y avoir des scénarios où vous souhaiterez peut-être mettre des objets de débogage à un
emplacement arbitraire, tel que le stockage externe lors de l'exécution de Valgrind sur un appareil mobile
avec un stockage local limité. Un autre exemple pourrait être une situation où vous n'avez pas
autorisation d'installer des packages d'objets de débogage sur le système sur lequel vous exécutez
Valgrind.

Dans ces scénarios, vous pouvez fournir un chemin absolu comme lieu final supplémentaire pour
Valgrind pour rechercher des objets de débogage en spécifiant
--extra-debuginfo-path=/chemin/vers/debug/objects. Le chemin donné sera précédé du
chemin absolu de l'objet recherché. Par exemple, si Valgrind recherche
les informations de débogage pour /w/x/y/zz.so et --extra-debuginfo-path=/a/b/c est spécifié, il sera
recherchez un objet de débogage dans /a/b/c/w/x/y/zz.so.

Ce drapeau ne doit être spécifié qu'une seule fois. S'il est spécifié plusieurs fois, seul le
la dernière instance est honorée.

--debuginfo-server=adresse IP:port [défaut: indéfini et inutilisé]
Il s'agit d'une nouvelle fonctionnalité expérimentale introduite dans la version 3.9.0.

Dans certains scénarios, il peut être pratique de lire les informations de débogage à partir d'objets stockés sur un
machine différente. Avec ce drapeau, Valgrind interrogera un serveur debuginfo exécuté sur
ipaddr et écoute sur le port du port, s'il ne trouve pas l'objet debuginfo dans le local
système de fichiers.

Le serveur debuginfo doit accepter les connexions TCP sur le port port. Le serveur debuginfo est
contenu dans le fichier source auxprogs/valgrind-di-server.c. Il ne servira qu'à partir de
le répertoire dans lequel il est démarré. le port par défaut est 1500 dans le client et le serveur si
non précisé.

Si Valgrind recherche les informations de débogage pour /w/x/y/zz.so en utilisant le serveur debuginfo, il
supprimera les composants du nom de chemin et demandera simplement zz.so sur le serveur. qu'en
turn recherchera uniquement dans son répertoire de travail actuel un objet debuginfo correspondant.

Les données de debuginfo sont transmises en petits fragments (8 Ko) comme demandé par Valgrind.
Chaque bloc est compressé à l'aide de LZO pour réduire le temps de transmission. La mise en œuvre a
a été réglé pour obtenir les meilleures performances sur une liaison réseau 802.11g (WiFi) à une étape.

Notez que vérifie la correspondance entre les objets primaires et les objets de débogage, en utilisant GNU debuglink CRC
schéma, sont effectuées même lors de l'utilisation du serveur debuginfo. Pour désactiver une telle vérification,
vous devez également spécifier --allow-mismatched-debuginfo=yes.

Par défaut, le système de build Valgrind construira valgrind-di-server pour la cible
plate-forme, ce qui n'est presque certainement pas ce que vous voulez. Jusqu'à présent, nous n'avons pas pu
découvrez comment obtenir automake/autoconf pour le construire pour la plate-forme de construction. Si tu veux
pour l'utiliser, vous devrez le recompiler à la main à l'aide de la commande indiquée en haut de
auxprogs/valgrind-di-server.c.

--allow-mismatched-debuginfo=non|oui [non]
Lors de la lecture de debuginfo à partir d'objets debuginfo séparés, Valgrind vérifiera par défaut
que les objets main et debuginfo correspondent, en utilisant le mécanisme de debuglink GNU. Cette
garantit qu'il ne lit pas debuginfo à partir d'objets debuginfo obsolètes, et
garantit également que Valgrind ne peut pas planter en raison de discordances.

Cette vérification peut être annulée en utilisant --allow-mismatched-debuginfo=yes. Cela peut être
utile lorsque les informations de débogage et les objets principaux n'ont pas été divisés correctement. Être
attention lorsque vous utilisez ceci, cependant: cela désactive toutes les vérifications de cohérence, et Valgrind
a été observé se bloquer lorsque les objets main et debuginfo ne correspondent pas.

--suppressions= [défaut: $PREFIX/lib/valgrind/default.supp]
Spécifie un fichier supplémentaire à partir duquel lire les descriptions des erreurs à supprimer. Tu peux
utiliser jusqu'à 100 fichiers de suppression supplémentaires.

--gen-suppressions= [défaut: non]
Lorsqu'il est configuré pour oui, Valgrind fera une pause après chaque erreur affichée et imprimera la ligne :

---- Suppression d'impression ? --- [Retour/N/n/O/y/C/c] ----

Nettoyage à sec rejet, ou N rejet or n rejet, oblige Valgrind à continuer l'exécution sans imprimer un
suppression de cette erreur.

Nettoyage à sec Y rejet or y rejet oblige Valgrind à écrire une suppression pour cette erreur. Vous pouvez
puis coupez-le et collez-le dans un fichier de suppression si vous ne voulez pas entendre parler du
erreur dans le futur.

Lorsqu'il est configuré pour tous, Valgrind imprimera une suppression pour chaque erreur signalée, sans
interroger l'utilisateur.

Cette option est particulièrement utile avec les programmes C++, car elle imprime le
suppressions avec des noms mutilés, selon les besoins.

Notez que les suppressions imprimées sont aussi précises que possible. Vous voudrez peut-être commun
des similaires, en ajoutant des caractères génériques aux noms de fonction et en utilisant le niveau du cadre
caractères génériques. Les fonctionnalités de joker sont puissantes mais flexibles, et avec un peu de
une édition minutieuse, vous pourrez peut-être supprimer toute une famille d'erreurs liées avec
seulement quelques suppressions.

Parfois, deux erreurs différentes sont supprimées par la même suppression, auquel cas
Valgrind affichera la suppression plus d'une fois, mais vous n'en aurez besoin que d'une
copier dans votre fichier de suppression (mais en avoir plusieurs ne causera pas de problèmes). Aussi,
le nom de suppression est donné comme ; le nom n'est pas
vraiment important, il n'est utilisé qu'avec le -v option qui imprime toutes les suppressions utilisées
Records.

--input-fd= [défaut: 0, entrée standard]
Lors de l'utilisation --gen-suppressions=oui, Valgrind s'arrêtera pour lire l'entrée du clavier
de vous lorsque chaque erreur se produit. Par défaut, il lit à partir de l'entrée standard (stdin),
ce qui est problématique pour les programmes qui ferment stdin. Cette option vous permet de spécifier
un descripteur de fichier alternatif à partir duquel lire l'entrée.

--dsymutil=non|oui [Oui]
Cette option n'est pertinente que lors de l'exécution de Valgrind sur Mac OS X.

Mac OS X utilise un schéma de liaison d'informations de débogage différé (debuginfo). Quand objet
les fichiers contenant debuginfo sont liés dans un .dylib ou un exécutable, le debuginfo est
pas copié dans le fichier final. Au lieu de cela, les informations de débogage doivent être liées manuellement par
exécuter dsymutil, un utilitaire fourni par le système, sur l'exécutable ou .dylib. Les
Les informations de débogage combinées résultantes sont placées dans un répertoire à côté de l'exécutable ou
.dylib, mais avec l'extension .dSYM.

Chez --dsymutil=non, Valgrind détectera les cas où le répertoire .dSYM est soit
manquant, ou est présent mais ne semble pas correspondre à l'exécutable associé ou
.dylib, probablement parce qu'il est obsolète. Dans ces cas, Valgrind imprimera un
message d'avertissement mais n'entreprenez aucune autre action.

Chez --dsymutil=oui, Valgrind exécutera, dans de tels cas, automatiquement dsymutil comme
nécessaire pour mettre à jour les informations de débogage. À toutes fins utiles, si vous toujours
utilisé --dsymutil=oui, alors il n'est jamais nécessaire d'exécuter dsymutil manuellement ou en tant que partie
du système de construction de vos applications, puisque Valgrind l'exécutera si nécessaire.

Valgrind ne tentera pas d'exécuter dsymutil sur un exécutable ou une bibliothèque dans / usr /,
/ poubelle /, / sbin /, / opt /, /sw/, /System/, /Library/ ou /Applications/ puisque dsymutil
échouent toujours dans de telles situations. Il échoue à la fois parce que les informations de débogage pour de tels
composants système préinstallés n'est disponible nulle part, et aussi parce qu'il
nécessitent des privilèges d'écriture dans ces répertoires.

Faites attention lorsque vous utilisez --dsymutil=oui, car cela provoquera un .dSYM préexistant
répertoires à supprimer et à recréer en silence. Notez également que dsymutil est assez
lent, parfois excessivement.

--max-stackframe= [défaut: 2000000]
La taille maximale d'un cadre de pile. Si le pointeur de pile se déplace de plus de ce montant
alors Valgrind supposera que le programme bascule vers une pile différente.

Vous devrez peut-être utiliser cette option si votre programme comporte de grands tableaux alloués à la pile.
Valgrind garde une trace du pointeur de pile de votre programme. S'il change de plus de
montant seuil, Valgrind suppose que votre programme passe à une pile différente, et
Memcheck se comporte différemment qu'il ne le ferait pour un changement de pointeur de pile plus petit que le
seuil. Habituellement, cette heuristique fonctionne bien. Cependant, si votre programme alloue de grandes
structures sur la pile, cette heuristique sera trompée, et Memcheck
signaler un grand nombre d'accès non valides à la pile. Cette option vous permet de modifier le
seuil à une valeur différente.

Vous ne devriez envisager d'utiliser cette option que si la sortie de débogage de Valgrind vous dirige vers
le faire. Dans ce cas, il vous indiquera le nouveau seuil que vous devez spécifier.

En général, allouer de grandes structures sur la pile est une mauvaise idée, car vous pouvez
manquer facilement d'espace de pile, en particulier sur les systèmes avec une mémoire limitée ou qui
attendez-vous à prendre en charge un grand nombre de threads chacun avec une petite pile, et aussi parce que
la vérification d'erreur effectuée par Memcheck est plus efficace pour les données allouées au tas
que pour les données allouées à la pile. Si vous devez utiliser cette option, vous souhaiterez peut-être
envisagez de réécrire votre code pour l'allouer sur le tas plutôt que sur la pile.

--main-stacksize= [défaut: utilisé actuel 'ulimite' valeur]
Spécifie la taille de la pile du thread principal.

Pour simplifier sa gestion de la mémoire, Valgrind réserve tout l'espace nécessaire pour le principal
pile du thread au démarrage. Cela signifie qu'il doit connaître la taille de pile requise à
Commencez.

Par défaut, Valgrind utilise la valeur "ulimit" actuelle pour la taille de la pile, soit 16 Mo,
celui qui est le plus bas. Dans de nombreux cas, cela donne une taille de pile comprise entre 8 et 16 Mo,
qui ne déborde presque jamais pour la plupart des applications.

Si vous avez besoin d'une plus grande taille de pile totale, utilisez --taille de la pile principale pour le préciser. Réglez-le seulement
aussi haut que vous en avez besoin, car vous réservez bien plus d'espace que vous n'en avez besoin (c'est-à-dire des centaines
de mégaoctets de plus que ce dont vous avez besoin) contraint les répartiteurs de mémoire de Valgrind et peut
réduire la quantité totale de mémoire que Valgrind peut utiliser. Ce n'est vraiment que de
importance sur les machines 32 bits.

Sous Linux, vous pouvez demander une pile d'une taille allant jusqu'à 2 Go. Valgrind s'arrêtera avec un
message de diagnostic si la pile ne peut pas être allouée.

--taille de la pile principale affecte uniquement la taille de la pile pour le thread initial du programme. Il a
aucune incidence sur la taille des piles de threads, car Valgrind ne les alloue pas.

Vous devrez peut-être utiliser les deux --taille de la pile principale et --max-stackframe ensemble. Il est
important de comprendre que --taille de la pile principale définit la taille totale maximale de la pile,
tandis que --max-stackframe spécifie la plus grande taille d'un cadre de pile. Vous serez
doivent travailler sur le --taille de la pile principale valeur pour vous-même (généralement, si votre
erreurs de segmentation des applications). Mais Valgrind vous dira le besoin --max-stackframe Taille,
si nécessaire.

Comme discuté plus loin dans la description de --max-stackframe, une exigence pour un grand
stack est un signe de problèmes potentiels de portabilité. Il est préférable de placer tous
des données volumineuses dans la mémoire allouée par tas.

--max-threads= [défaut: 500]
Par défaut, Valgrind peut gérer jusqu'à 500 threads. Parfois, ce nombre est trop
petit. Utilisez cette option pour fournir une limite différente. Par exemple --max-threads=3000.

LIÉ À MALLOC() OPTIONS

Pour les outils qui utilisent leur propre version de malloc (par exemple Memcheck, Massif, Helgrind, DRD), le
les options suivantes s'appliquent.

--alignement= [défaut: 8 or 16 en fonction on le Plate-forme]
Par défaut Valgrind malloc, réallouer, etc, renvoient un bloc dont l'adresse de départ est
Aligné sur 8 octets ou aligné sur 16 octets (la valeur dépend de la plate-forme et correspond au
plate-forme par défaut). Cette option vous permet de spécifier un alignement différent. Les
la valeur fournie doit être supérieure ou égale à la valeur par défaut, inférieure ou égale à
4096, et doit être une puissance de deux.

--redzone-size= [défaut: dépend on le outil]
de Valgrind malloc, réallouer, etc, ajoutez des blocs de remplissage avant et après chaque bloc de tas
alloués par le programme en cours d'exécution. De tels blocs de remplissage sont appelés zones rouges. Les
la valeur par défaut de la taille de la zone rouge dépend de l'outil. Par exemple, Memcheck ajoute et
protège au minimum 16 octets avant et après chaque bloc alloué par le client.
Cela lui permet de détecter des dépassements de blocs ou des dépassements jusqu'à 16 octets.

L'augmentation de la taille de la zone rouge permet de détecter des dépassements de distances plus importantes,
mais augmente la quantité de mémoire utilisée par Valgrind. Diminuer la taille de la zone rouge
réduit la mémoire nécessaire à Valgrind mais réduit également les chances de détecter
dépassements/dépassements, n'est donc pas recommandé.

RARE OPTIONS

Ces options s'appliquent à tous les outils, car elles affectent certains fonctionnements obscurs du Valgrind
coeur. La plupart des gens n'auront pas besoin de les utiliser.

--smc-check= [défaut: tout-non-fichier pour x86/amd64/s390x,
empiler pour autre arcs]
Cette option contrôle la détection par Valgrind du code auto-modifiant. Si aucune vérification n'est
terminé, lorsqu'un programme exécute du code, puis l'écrase avec un nouveau code, et
exécute le nouveau code, Valgrind continuera à exécuter les traductions qu'il a effectuées pour
l'ancien code. Cela entraînera probablement un comportement incorrect et/ou des plantages.

Pour les architectures "modernes" -- tout ce qui n'est pas x86, amd64 ou s390x -- la valeur par défaut
is empiler. C'est parce qu'un programme correct doit prendre des mesures explicites pour rétablir
Cohérence du cache DI suite à la modification du code. Valgrind observe et honore ces
actions, avec pour résultat que le code auto-modifiable est géré de manière transparente avec zéro
coût supplémentaire.

Pour x86, amd64 et s390x, le programme n'est pas obligé de notifier le matériel de
synchronisation de cohérence DI requise. Par conséquent, la valeur par défaut est tout-non-fichier, qui couvre la
cas normal de génération de code dans une zone mmap'd anonyme (non sauvegardée par fichier).

Les significations des quatre réglages disponibles sont les suivantes. Pas de détection (aucun),
détecter le code auto-modifiant sur la pile (qui est utilisé par GCC pour implémenter
les fonctions) (empiler), détecter partout le code auto-modifiable (tous) et détecter
code auto-modifiable partout sauf dans les mappages sauvegardés sur fichier (tout-non-fichier).

Courir avec tous ralentira considérablement Valgrind. Courir avec aucun sera rarement
accélérer les choses, car très peu de code est généré dynamiquement dans la plupart des programmes.
La VALGRIND_DISCARD_TRANSLATIONS la demande du client est une alternative à --smc-check=tout
et --smc-check=tout-non-fichier qui demande plus d'efforts au programmeur mais permet à Valgrind
pour exécuter votre programme plus rapidement, en lui indiquant précisément quand les traductions doivent être
refait.

--smc-check=tout-non-fichier fournit une version moins chère mais plus limitée de
--smc-check=tout. Il ajoute des vérifications à toutes les traductions qui ne proviennent pas de
mappages de mémoire sauvegardés sur fichier. Applications typiques qui génèrent du code, par exemple des JIT
dans les navigateurs Web, générez du code dans des zones Mmap anonymes, tandis que le code « fixe »
du navigateur vit toujours dans des mappages sauvegardés sur des fichiers. --smc-check=tout-non-fichier prend
avantage de cette observation, en limitant le surcoût de la vérification au code qui est
susceptible d'être généré par JIT.

--read-inline-info= [défaut: sur le lien au dessous de]
Lorsqu'il est activé, Valgrind lira les informations sur les appels de fonction en ligne de DWARF3
les informations de débogage. Cela ralentit le démarrage de Valgrind et lui fait utiliser plus de mémoire (généralement pour
chaque morceau de code inséré, 6 mots et un espace pour le nom de la fonction), mais il en résulte
dans des stacktraces plus descriptives. Pour la version 3.10.0, cette fonctionnalité est activée
par défaut uniquement pour les cibles Linux, Android et Solaris et uniquement pour les outils
Memcheck, Helgrind et DRD. Voici un exemple de quelques stacktraces avec
--read-inline-info=non:

==15380== Le saut ou le déplacement conditionnel dépend de la (des) valeur(s) non initialisée(s)
==15380== à 0x80484EA : principal (inlinfo.c:6)
==15380==
==15380== Le saut ou le déplacement conditionnel dépend de la (des) valeur(s) non initialisée(s)
==15380== à 0x8048550 : fun_noninline (inlinfo.c:6)
==15380== par 0x804850E : principal (inlinfo.c:34)
==15380==
==15380== Le saut ou le déplacement conditionnel dépend de la (des) valeur(s) non initialisée(s)
==15380== à 0x8048520 : principal (inlinfo.c:6)

Et voici les mêmes erreurs avec --read-inline-info=oui:

==15377== Le saut ou le déplacement conditionnel dépend de la (des) valeur(s) non initialisée(s)
==15377== à 0x80484EA : fun_d (inlinfo.c:6)
==15377== par 0x80484EA : fun_c (inlinfo.c:14)
==15377== par 0x80484EA : fun_b (inlinfo.c:20)
==15377== par 0x80484EA : fun_a (inlinfo.c:26)
==15377== par 0x80484EA : principal (inlinfo.c:33)
==15377==
==15377== Le saut ou le déplacement conditionnel dépend de la (des) valeur(s) non initialisée(s)
==15377== à 0x8048550 : fun_d (inlinfo.c:6)
==15377== par 0x8048550 : fun_noninline (inlinfo.c:41)
==15377== par 0x804850E : principal (inlinfo.c:34)
==15377==
==15377== Le saut ou le déplacement conditionnel dépend de la (des) valeur(s) non initialisée(s)
==15377== à 0x8048520 : fun_d (inlinfo.c:6)
==15377== par 0x8048520 : principal (inlinfo.c:35)

--read-var-info= [défaut: non]
Lorsqu'il est activé, Valgrind lira des informations sur les types de variables et les emplacements à partir de
Informations de débogage DWARF3. Cela ralentit considérablement le démarrage de Valgrind et l'oblige à utiliser
beaucoup plus de mémoire, mais pour les outils qui peuvent en profiter (Memcheck,
Helgrind, DRD), il peut en résulter des messages d'erreur plus précis. Par exemple, voici
quelques erreurs standard émises par Memcheck :

==15363== Octet(s) non initialisé(s) trouvé(s) lors de la demande de contrôle client
==15363== à 0x80484A9 : croasser (varinfo1.c:28)
==15363== par 0x8048544 : principal (varinfo1.c:55)
==15363== L'adresse 0x80497f7 est de 7 octets à l'intérieur du symbole de données "global_i2"
==15363==
==15363== Octet(s) non initialisé(s) trouvé(s) lors de la demande de contrôle client
==15363== à 0x80484A9 : croasser (varinfo1.c:28)
==15363== par 0x8048550 : principal (varinfo1.c:56)
==15363== L'adresse 0xbea0d0cc est sur la pile du thread 1
==15363== dans le cadre #1, créé par main (varinfo1.c:45)

Et voici les mêmes erreurs avec --read-var-info=oui:

==15370== Octet(s) non initialisé(s) trouvé(s) lors de la demande de contrôle client
==15370== à 0x80484A9 : croasser (varinfo1.c:28)
==15370== par 0x8048544 : principal (varinfo1.c:55)
==15370== L'emplacement 0x80497f7 est de 0 octet dans global_i2[7],
==15370== une variable globale déclarée à varinfo1.c:41
==15370==
==15370== Octet(s) non initialisé(s) trouvé(s) lors de la demande de contrôle client
==15370== à 0x80484A9 : croasser (varinfo1.c:28)
==15370== par 0x8048550 : principal (varinfo1.c:56)
==15370== L'emplacement 0xbeb4a0cc est de 0 octet dans la var locale "local"
==15370== déclaré à varinfo1.c:46, dans le cadre #1 du thread 1

--vgdb-sondage= [défaut: 5000]
Dans le cadre de sa boucle principale, le planificateur Valgrind interrogera pour vérifier si une activité
(telle qu'une commande externe ou une entrée d'un gdb) doit être gérée par gdbserver.
Ce sondage d'activité sera effectué après avoir exécuté le nombre donné de blocs de base (ou
légèrement plus que le nombre donné de blocs de base). Ce sondage est assez bon marché donc le
la valeur par défaut est définie relativement faible. Vous pouvez encore diminuer cette valeur si vgdb
ne peut pas utiliser l'appel système ptrace pour interrompre Valgrind si tous les threads sont (la plupart des
time) bloqué dans un appel système.

--vgdb-shadow-registers=non|oui [défaut: non]
Lorsqu'il est activé, gdbserver exposera les registres fantômes Valgrind à GDB. Avec ça,
la valeur des registres fantômes Valgrind peut être examinée ou modifiée à l'aide de GDB.
L'exposition des registres fantômes ne fonctionne qu'avec la version 7.1 ou ultérieure de GDB.

--vgdb-prefix= [défaut: /tmp/vgdb-pipe]
Pour communiquer avec gdb/vgdb, le Valgrind gdbserver crée 3 fichiers (2 nommés FIFO
et un fichier de mémoire partagée mmap). L'option préfixe contrôle le répertoire et le préfixe
pour la création de ces fichiers.

--run-libc-freeres= [défaut: Oui]
Cette option n'est pertinente que lors de l'exécution de Valgrind sous Linux.

La bibliothèque GNU C (libc.so), qui est utilisé par tous les programmes, peut allouer de la mémoire pour
ses propres usages. Habituellement, cela ne prend pas la peine de libérer cette mémoire lorsque le programme se termine—
cela ne servirait à rien, puisque le noyau Linux récupère toutes les ressources de processus lorsqu'un
le processus se termine de toute façon, donc cela ne ferait que ralentir les choses.

Les auteurs de la glibc se sont rendu compte que ce comportement provoquait des vérificateurs de fuites, tels que Valgrind,
pour signaler faussement les fuites dans la glibc, lorsqu'un contrôle des fuites est effectué à la sortie. Pour éviter
cela, ils ont fourni une routine appelée __libc_freeres spécifiquement pour publier la glibc
toute la mémoire qu'il a allouée. Memcheck essaie donc d'exécuter __libc_freeres à la sortie.

Malheureusement, dans certaines très anciennes versions de la glibc, __libc_freeres est suffisamment
buggy pour provoquer des défauts de segmentation. Cela était particulièrement visible sur Red Hat 7.1.
Cette option est donc prévue afin d'inhiber l'exécution de __libc_freeres. Si votre
le programme semble fonctionner correctement sur Valgrind, mais des erreurs de segmentation à la sortie, vous pouvez constater que
--run-libc-freeres=non corrige cela, bien qu'au prix d'éventuelles fausses déclarations
fuites d'espace dans libc.so.

--sim-hints=indice1,indice2,...
Transmettez diverses astuces à Valgrind qui modifient légèrement le comportement simulé dans
manières non standard ou dangereuses, éventuellement pour aider à la simulation de caractéristiques étranges. Par
par défaut, aucun conseil n'est activé. Utiliser avec précaution! Les astuces actuellement connues sont :

· lax-ioctls : Soyez très laxiste quant à la gestion d'ioctl ; la seule hypothèse est que la taille
est correct. Ne nécessite pas l'initialisation de la mémoire tampon complète lors de l'écriture.
Sans cela, en utilisant certains pilotes de périphériques avec un grand nombre d'ioctl étranges
commandes devient très fastidieux.

· compatible avec les fusibles : Activer un traitement spécial pour certains appels système susceptibles de bloquer
dans un système de fichiers FUSE. Cela peut être nécessaire lors de l'exécution de Valgrind sur un
programme multithread qui utilise un thread pour gérer un système de fichiers FUSE et
un autre thread pour accéder à ce système de fichiers.

· activer-externe : Activer une magie spéciale nécessaire lorsque le programme en cours d'exécution est
lui-même Valgrind.

· pas de préfixe interne : Désactiver l'impression d'un préfixe > devant chaque stdout ou stderr
ligne de sortie dans un Valgrind interne géré par un Valgrind externe. C'est utile
lors de l'exécution des tests de régression Valgrind dans une configuration externe/interne. Notez que le
préfixe > sera toujours imprimé devant les lignes de journalisation de débogage internes.

· no-nptl-pthread-stackcache : Cette astuce n'est pertinente que lors de l'exécution de Valgrind sur
Linux.

La bibliothèque GNU glibc pthread (libpthread.so), qui est utilisé par les programmes pthread,
maintient un cache de piles pthread. Lorsqu'un pthread se termine, la mémoire utilisée
pour la pile pthread et certaines structures de données liées au stockage local des threads ne sont pas
toujours directement libéré. Cette mémoire est conservée dans un cache (jusqu'à une certaine taille),
et est réutilisé si un nouveau thread est démarré.

Ce cache amène l'outil helgrind à signaler une condition de concurrence faussement positive
erreurs sur cette mémoire cache, car helgrind ne comprend pas la glibc interne
primitives de synchronisation de cache. Ainsi, lors de l'utilisation de helgrind, la désactivation du cache
permet d'éviter les conditions de concurrence faussement positives, en particulier lors de l'utilisation de threads
les variables de stockage locales (par exemple les variables utilisant le __fil qualificatif).

Lors de l'utilisation de l'outil memcheck, la désactivation du cache garantit la mémoire utilisée par la glibc
pour gérer les variables __thread est directement libéré lorsqu'un thread se termine.

Remarque : Valgrind désactive le cache en utilisant certaines connaissances internes de la pile glibc
implémentation du cache et en examinant les informations de débogage du pthread
une bibliothèque. Cette technique est donc un peu fragile et risque de ne pas fonctionner pour toutes les glibc
versions. Ceci a été testé avec succès avec diverses versions de la glibc (par ex.
2.11, 2.16, 2.18) sur diverses plateformes.

· lax-portes: (Solaris uniquement) Soyez très laxiste quant à la gestion des appels système de porte
descripteurs de fichiers de porte non reconnus. Ne nécessite pas que la mémoire tampon pleine soit
initialisé lors de l'écriture. Sans cela, les programmes utilisant libdoor(3LIB) fonctionnalité
avec une sémantique entièrement propriétaire peut signaler un grand nombre de faux positifs.

--fair-sched= [défaut: non]
La --fair-sched L'option contrôle le mécanisme de verrouillage utilisé par Valgrind pour sérialiser
exécution du fil. Le mécanisme de verrouillage contrôle la façon dont les threads sont planifiés,
et différents paramètres donnent différents compromis entre l'équité et la performance. Pour
plus de détails sur le schéma de sérialisation des threads Valgrind et son impact sur
performances et planification des threads, voir Planification et performances multi-thread.

· La valeur --fair-sched=oui active un programmateur équitable. Bref, si plusieurs
les threads sont prêts à être exécutés, les threads seront planifiés de manière circulaire.
Ce mécanisme n'est pas disponible sur toutes les plateformes ou versions de Linux. Si non
disponible, en utilisant --fair-sched=oui entraînera la fin de Valgrind avec une erreur.

Vous constaterez peut-être que ce paramètre améliore la réactivité globale si vous exécutez un
programme multithread interactif, par exemple un navigateur Web, sur Valgrind.

· La valeur --fair-sched=essayer active la programmation équitable si disponible sur la plateforme.
Sinon, il retombera automatiquement sur --fair-sched=non.

· La valeur --fair-sched=non active un ordonnanceur qui ne garantit pas l'équité
entre les threads prêts à s'exécuter, mais qui donne en général les meilleures performances.

--kernel-variant=variante1,variante2,...
Gérer les appels système et les ioctls provenant de variantes mineures du noyau par défaut pour
cette plate-forme. Ceci est utile pour exécuter sur des noyaux piratés ou avec des modules de noyau
qui prennent en charge les ioctls non standard, par exemple. Utiliser avec précaution. Si vous ne
comprendre ce que fait cette option, alors vous n'en avez presque certainement pas besoin. Actuellement
les variantes connues sont :

· bproc: soutenir le sys_broc appel système sur x86. C'est pour fonctionner sur BProc,
qui est une variante mineure de Linux standard qui est parfois utilisée pour construire
groupes.

· android-pas-hw-tls: certaines versions de l'émulateur Android pour ARM ne fournissent pas de
registre matériel TLS (thread-local state) et Valgrind se bloque au démarrage. Utilisation
cette variante pour sélectionner le support logiciel pour TLS.

· android-gpu-sgx5xx: utilisez ceci pour prendre en charge la gestion des ioctls propriétaires pour le
Série de GPU PowerVR SGX 5XX sur les appareils Android. Ne pas sélectionner cette option ne
causer des problèmes de stabilité, mais peut amener Memcheck à signaler de fausses erreurs après la
programme exécute des ioctls spécifiques au GPU.

· android-gpu-adreno3xx: de la même manière, utilisez ceci pour prendre en charge la gestion des fichiers propriétaires
ioctls pour la série de GPU Qualcomm Adreno 3XX sur les appareils Android.

--merge-recursive-frames= [défaut: 0]
Certains algorithmes récursifs, par exemple les implémentations d'arbres binaires équilibrés, créent
de nombreuses traces de pile différentes, chacune contenant des cycles d'appels. Un cycle est défini comme
deux valeurs de compteur de programme identiques séparées par zéro ou plusieurs autres compteurs de programme
valeurs. Valgrind peut alors utiliser beaucoup de mémoire pour stocker toutes ces traces de pile. C'est
une mauvaise utilisation de la mémoire étant donné que de telles traces de pile contiennent des répétitions inintéressantes
appels récursifs au lieu d'informations plus intéressantes telles que la fonction qui a
a lancé l'appel récursif.

L'option --merge-recursive-frames= demande à Valgrind de détecter et de fusionner
cycles d'appels récursifs ayant une taille allant jusqu'à cadres. Lorsqu'un tel cycle est
détecté, Valgrind enregistre le cycle dans la trace de la pile en tant que compteur de programme unique.

La valeur 0 (la valeur par défaut) ne provoque aucune fusion d'appels récursive. Une valeur de 1 entraînera
empiler des traces d'algorithmes récursifs simples (par exemple, une implémentation factorielle)
être effondré. Une valeur de 2 sera généralement nécessaire pour réduire les traces de pile produites
par des algorithmes récursifs tels que les arbres binaires, le tri rapide, etc. Des valeurs plus élevées peuvent être
nécessaires pour des algorithmes récursifs plus complexes.

Remarque : les appels récursifs sont détectés par analyse des valeurs des compteurs de programme. Ils ne sont pas
détecté en regardant les noms de fonction.

--num-transtab-sectors= [défaut: 6 pour Android plates-formes, 16 pour tous autres]
Valgrind traduit et instrumente le code machine de votre programme en petits fragments
(blocs de base). Les traductions sont stockées dans un cache de traduction qui est divisé
en plusieurs sections (secteurs). Si le cache est plein, le secteur contenant le
traductions les plus anciennes est vidé et réutilisé. Si ces anciennes traductions sont à nouveau nécessaires,
Valgrind doit retraduire et réinstrumenter le code machine correspondant, qui est
cher. Si l'ensemble de travail « instructions exécutées » d'un programme est grand, augmenter
le nombre de secteurs peut améliorer les performances en réduisant le nombre de
retraductions nécessaires. Les secteurs sont attribués à la demande. Une fois attribué, un secteur peut
jamais être libéré, et occupe un espace considérable, selon l'outil et la valeur
of --avg-transtab-entry-size (environ 40 Mo par secteur pour Memcheck). Utilisez l'option
--stats=oui pour obtenir des informations précises sur la mémoire utilisée par un secteur et la
répartition et recyclage des filières.

--avg-transtab-entry-size= [défaut: 0, sens utilisé outil à condition de défaut]
Taille moyenne du bloc de base traduit. Cette taille moyenne est utilisée pour dimensionner le
taille d'un secteur. Chaque outil fournit une valeur par défaut à utiliser. Si cette valeur par défaut
est trop petit, les secteurs de traduction se rempliront trop rapidement. Si cette valeur par défaut
valeur est trop grande, une partie importante de la mémoire du secteur de traduction sera inutilisée.
Notez que la taille moyenne d'une traduction de bloc de base dépend de l'outil, et peut
dépendent des options de l'outil. Par exemple, l'option memcheck --track-origins=oui des augmentations
la taille des traductions de blocs de base. Utilisation --avg-transtab-entry-size pour régler le
taille des secteurs, soit pour gagner de la mémoire, soit pour éviter trop de retraductions.

--aspace-minaddr= [défaut: dépend on le Plate-forme]
Pour éviter des conflits potentiels avec certaines bibliothèques système, Valgrind n'utilise pas le
espace d'adressage ci-dessous --aspace-minaddr valeur, en la gardant réservée au cas où une bibliothèque
demande spécifiquement de la mémoire dans cette région. Ainsi, une valeur "pessimiste" est devinée
par Valgrind selon la plateforme. Sous Linux, par défaut, Valgrind évite d'utiliser le
premiers 64 Mo même s'il n'y a généralement pas de conflit dans cette zone complète. Vous pouvez utiliser
l'option --aspace-minaddr pour faire profiter votre application gourmande en mémoire
plus de cette mémoire inférieure. En revanche, si vous rencontrez un conflit, augmenter
La valeur aspace-minaddr pourrait le résoudre. Les conflits se manifesteront généralement avec
échecs mmap dans la plage basse de l'espace d'adressage. L'adresse fournie doit être la page
aligné et doit être égal ou supérieur à 0x1000 (4KB). Pour trouver la valeur par défaut sur votre
plate-forme, faites quelque chose comme valgrind -d -d date 2>&1 | grep -i minaddr. Valeurs
inférieur à 0x10000 (64 Ko) sont connus pour créer des problèmes sur certaines distributions.

--valgrind-stacksize= [défaut: 1 Mo]
Pour chaque thread, Valgrind a besoin de sa propre pile « privée ». La taille par défaut pour ces
stacks est largement dimensionné et devrait donc être suffisant dans la plupart des cas. Au cas où le
la taille est trop petite, Valgrind fera une erreur de segmentation. Avant de segfault, un avertissement peut être
produit par Valgrind à l'approche de la limite.

Utilisez l'option --valgrind-stacksize si un tel avertissement (peu probable) est produit, ou
Valgrind meurt à cause d'une violation de segmentation. De telles violations de segmentation ont été
vu lors du démêlage d'énormes symboles C++.

Si votre application utilise de nombreux threads et a besoin de beaucoup de mémoire, vous pouvez gagner
mémoire en réduisant la taille de ces piles Valgrind en utilisant l'option
--valgrind-stacksize.

--show-emwarns= [défaut: non]
Lorsqu'il est activé, Valgrind émettra des avertissements sur son émulation CPU dans certains cas.
Ceux-ci ne sont généralement pas intéressants.

--require-text-symbol=:sonamepatt:fnnamepatt
Lorsqu'un objet partagé dont le nom correspond sonamepatt est chargé dans le processus,
examiner tous les symboles de texte qu'il exporte. Si aucun de ceux-ci ne correspond fnnamepatt, imprimez un
message d'erreur et abandonner l'exécution. Cela permet de s'assurer que la course ne
pas continuer à moins qu'un objet partagé donné ne contienne un nom de fonction particulier.

Le sonamepatt et fnnamepatt peut être écrit en utilisant l'habituel ? et * caractères génériques. Pour
Exemple: ":*libc.so*:foo?bar". Vous pouvez utiliser des caractères autres que deux points pour séparer
les deux motifs. Il est seulement important que le premier caractère et le séparateur
caractère sont les mêmes. Par exemple, l'exemple ci-dessus pourrait également être écrit
"Q*libc.so*Qfoo?bar". Plusieurs
--require-text-symbole les drapeaux sont autorisés, auquel cas les objets partagés qui sont chargés
dans le processus sera vérifié par rapport à chacun d'eux.

Le but de ceci est de prendre en charge une utilisation fiable des bibliothèques balisées. Par exemple,
supposons que nous ayons une version de GCC libgomp.so qui a été marqué avec
annotations pour soutenir Helgrind. Il n'est que trop facile et déroutant de charger le mauvais,
non annoté libgomp.so dans l'application. Donc l'idée est : ajouter un symbole de texte dans le
bibliothèque balisée, par exemple annoté_pour_helgrind_3_6, puis donner le drapeau
--require-text-symbol=:*libgomp*so*:annotated_for_helgrind_3_6 de sorte que quand libgomp.so
est chargé, Valgrind scanne sa table de symboles, et si le symbole n'est pas présent, l'exécution est
abandonné, plutôt que de continuer en silence avec la bibliothèque non balisée. Notez que vous
devrait mettre le drapeau entier entre guillemets pour empêcher les shells de se développer * et ?
caractères génériques.

--soname-synonyms=syn1=motif1,syn2=motif2,...
Lorsqu'une bibliothèque partagée est chargée, Valgrind vérifie les fonctions dans la bibliothèque qui
doit être remplacé ou emballé. Par exemple, Memcheck remplace tous les mallocs liés
fonctions (malloc, free, calloc, ...) avec ses propres versions. De tels remplacements sont
fait par défaut uniquement dans les bibliothèques partagées dont le nom correspond à un nom prédéfini
modèle (par exemple libc.so* sous linux). Par défaut, aucun remplacement n'est effectué pour un
bibliothèque liée ou pour des bibliothèques alternatives telles que tcmalloc. Dans certains cas, le
les remplacements permettent --soname-synonymes pour spécifier un modèle de synonyme supplémentaire, donnant
flexibilité dans le remplacement.

Actuellement, cette flexibilité n'est autorisée que pour les fonctions liées à malloc, en utilisant
le synonyme somalloc. Ce synonyme est utilisable pour tous les outils faisant du remplacement standard
des fonctions liées à malloc (par exemple memcheck, massif, drd, helgrind, exp-dhat,
exp-sgcheck).

· Bibliothèque malloc alternative : pour remplacer les fonctions liées à malloc dans une alternative
bibliothèque avec soname mymalloclib.so, donner l'option
--soname-synonyms=somalloc=mymalloclib.so. Un modèle peut être utilisé pour correspondre à plusieurs
bibliothèques sonames. Par exemple, --soname-synonyms=somalloc=*tcmalloc* correspondra
le soname de toutes les variantes de la librairie tcmalloc (native, debug, profiled, ...
variantes de tcmalloc).

Remarque : le soname d'une bibliothèque partagée elfe peut être récupéré à l'aide du readelf
utilitaire.

· Les remplacements dans une bibliothèque liée statiquement sont effectués en utilisant le NONE motif.
Par exemple, si vous créez un lien avec libtcmalloc.a, memcheck fonctionnera correctement lorsque vous
donner la possibilité --soname-synonyms=somalloc=AUCUN. Notez qu'un motif NONE
correspondre à l'exécutable principal et à toute bibliothèque partagée n'ayant pas de nom de son.

· Pour exécuter une version Firefox "par défaut" pour Linux, dans laquelle JEMalloc est lié au
exécutable principal, utilisez --soname-synonyms=somalloc=AUCUN.

DÉBOGAGE VALGRIND OPTIONS

Il existe également des options pour le débogage de Valgrind lui-même. Vous ne devriez pas avoir besoin de les utiliser
dans le cours normal des choses. Si vous souhaitez voir la liste, utilisez le --help-débogage option.

CONTRLE MÉMOIRE OPTIONS

--leak-check= [défaut: sommaire]
Lorsque cette option est activée, recherchez les fuites de mémoire lorsque le programme client se termine. Si réglé sur
Sommaire, il indique combien de fuites se sont produites. Si réglé sur plein or oui, chaque fuite individuelle
sera affiché en détail et/ou compté comme une erreur, comme spécifié par les options
--show-leak-types et --erreurs-pour-les-types de fuites.

--leak-resolution= [défaut: haute]
Lors de la vérification des fuites, détermine dans quelle mesure Memcheck est disposé à considérer différents
les backtraces soient les mêmes dans le but de fusionner plusieurs fuites en un seul
rapport de fuite. Lorsqu'il est réglé sur faible, seules les deux premières entrées doivent correspondre. Lorsque de, quatre
les entrées doivent correspondre. Lorsque Élevée, toutes les entrées doivent correspondre.

Pour le débogage de fuite hardcore, vous voudrez probablement utiliser --leak-resolution=élevé together
avec --num-appelants=40 ou un si grand nombre.

Notez que le --résolution de fuite le paramètre n'affecte pas la capacité de Memcheck à trouver
fuites. Cela ne change que la façon dont les résultats sont présentés.

--show-leak-kinds= [défaut: défini, possible]
Spécifie les types de fuite à afficher dans un plein recherche de fuite, de l'une des manières suivantes :

· une liste séparée par des virgules d'un ou plusieurs de précis indirect possible accessible.

· tous pour spécifier l'ensemble complet (tous types de fuites). C'est équivalent à
--show-leak-kinds=definite,indirect,possible,accessible.

· aucun pour l'ensemble vide.

--errors-for-leak-kind= [défaut: défini, possible]
Spécifie les types de fuite à compter comme erreurs dans un plein recherche de fuite. Les is
spécifié de la même manière que --show-leak-types

--leak-check-heuristique= [défaut: tous]
Spécifie l'ensemble d'heuristiques de vérification des fuites à utiliser lors des recherches de fuites. Les
les heuristiques contrôlent quels pointeurs intérieurs vers un bloc le font être considéré comme
accessible. L'ensemble heuristique est spécifié de l'une des manières suivantes :

· une liste séparée par des virgules d'un ou plusieurs de chaîne std longueur64 nouvelle matrice
héritage multiple.

· tous pour activer l'ensemble complet des heuristiques. C'est équivalent à
--leak-check-heuristics=chaîne standard,longueur64,newarray,héritage multiple.

· aucun pour l'ensemble vide.

Notez que ces heuristiques dépendent de la disposition des objets produits par le
compilateur C++. Ils ont été testés avec certaines versions de gcc (par exemple 4.4 et 4.7). Ils
peut ne pas fonctionner correctement avec d'autres compilateurs C++.

--show-accessible= , --show-possably-lost=
Ces options offrent un autre moyen de spécifier les types de fuites à afficher :

· --show-reachable=non --show-possably-lost=oui équivaut à
--show-leak-kinds=défini,possible.

· --show-reachable=non --show-possably-lost=no équivaut à
--show-leak-kinds=définitif.

· --show-reachable=oui équivaut à --show-leak-kinds=tous.

Notez que --show-possably-lost=no n'a aucun effet si --show-reachable=oui est spécifié.

--undef-value-errors= [défaut: Oui]
Contrôle si les rapports Memcheck utilisent des erreurs de valeur non définies. Réglez ceci sur aucune if
vous ne voulez pas voir d'erreurs de valeur indéfinies. Il a également pour effet secondaire d'accélérer
un peu Memcheck.

--track-origins= [défaut: non]
Contrôle si Memcheck suit l'origine des valeurs non initialisées. Par défaut, il
ne le fait pas, ce qui signifie que bien qu'il puisse vous dire qu'une valeur non initialisée est
utilisé de manière dangereuse, il ne peut pas vous dire d'où vient la valeur non initialisée
de. Cela rend souvent difficile la recherche de la racine du problème.

Lorsqu'il est configuré pour oui, Memcheck garde une trace de l'origine de toutes les valeurs non initialisées.
Ensuite, lorsqu'une erreur de valeur non initialisée est signalée, Memcheck essaiera d'afficher le
origine de la valeur. Une origine peut être l'un des quatre emplacements suivants : un bloc de tas,
une allocation de pile, une demande client ou diverses autres sources (par exemple, un appel à
brk).

Pour les valeurs non initialisées provenant d'un bloc de tas, Memcheck montre où le bloc
a été alloué. Pour les valeurs non initialisées provenant d'une allocation de pile, Memcheck
peut vous dire quelle fonction a attribué la valeur, mais pas plus que cela - généralement, il
vous montre l'emplacement source de l'accolade ouvrante de la fonction. Ainsi vous devriez
vérifiez soigneusement que toutes les variables locales de la fonction sont correctement initialisées.

Surcharge de performances : le suivi de l'origine est coûteux. Il réduit de moitié la vitesse de Memcheck et
augmente l'utilisation de la mémoire d'au moins 100 Mo, voire plus. Néanmoins il peut
réduire considérablement l'effort requis pour identifier la cause première des erreurs non initialisées
erreurs de valeur, et c'est souvent une victoire de productivité du programmeur, malgré l'exécution de plus
lentement.

Précision : Memcheck suit les origines de manière assez précise. Pour éviter de très grands espaces et temps
frais généraux, quelques approximations sont faites. Il est possible, bien qu'improbable, que
Memcheck signalera une origine incorrecte ou ne pourra identifier aucune origine.

A noter que la combinaison --track-origins=oui et --undef-value-errors=non is
absurde. Memcheck vérifie et rejette cette combinaison au démarrage.

--partial-loads-ok= [défaut: Oui]
Contrôle la façon dont Memcheck gère les charges 32, 64, 128 et 256 bits naturellement alignées à partir de
adresses pour lesquelles certains octets sont adressables et d'autres non. Lorsque oui, tel
les charges ne produisent pas d'erreur d'adresse. Au lieu de cela, les octets chargés provenant de sources illégales
les adresses sont marquées comme non initialisées, et celles correspondant aux adresses légales sont
traitées de manière normale.

Lorsque aucune, les chargements provenant d'adresses partiellement invalides sont traités de la même manière que les chargements provenant de
adresses complètement invalides : une erreur d'adresse illégale est émise et le résultat
les octets sont marqués comme initialisés.

Notez que le code qui se comporte de cette manière est en violation des normes ISO C/C++,
et doit être considéré comme cassé. Si possible, ce code doit être corrigé.

--expensive-definedness-checks= [défaut: non]
Contrôle si Memcheck doit utiliser des méthodes plus précises mais aussi plus coûteuses (temps
consommer) algorithmes lors de la vérification de la définition d'une valeur. Le paramètre par défaut est
de ne pas le faire et c'est généralement suffisant. Cependant, pour un code hautement optimisé
valgrind peut parfois se plaindre à tort. Invoquer valgrind avec
--expensive-definedness-checks=oui aide mais a un coût en termes de performances. Durée
dégradation de 25 % ont été observées mais le surcoût dépend beaucoup de la
application à portée de main.

--keep-stacktraces=alloc|free|alloc-and-free|alloc-then-free|aucun [défaut:
allouer et gratuitement]
Contrôle la ou les traces de pile à conserver pour les blocs mallocés et/ou libérés.

Chez allouer-alors-gratuit, une trace de pile est enregistrée au moment de l'allocation et est associée
avec le bloc. Lorsque le bloc est libéré, une seconde trace de pile est enregistrée, et cette
remplace la trace de la pile d'allocation. En conséquence, toute erreur « utilisation après gratuit » concernant
à ce bloc ne peut afficher qu'une trace de pile pour l'endroit où le bloc a été libéré.

Chez allouer et gratuitement, à la fois l'allocation et les traces de la pile de désallocation pour le bloc
sont stockés. Par conséquent, une erreur "utiliser après gratuit" affichera les deux, ce qui peut provoquer l'erreur
plus facile à diagnostiquer. Par rapport à allouer-alors-gratuit, ce réglage augmente légèrement
L'utilisation de la mémoire de Valgrind en tant que bloc contient deux références au lieu d'une.

Chez allouer, seule la trace de la pile d'allocation est enregistrée (et signalée). Avec gratuitement,
seule la trace de la pile de désallocation est enregistrée (et signalée). Ces valeurs quelque peu
diminuer l'utilisation de la mémoire et du processeur de Valgrind. Ils peuvent être utiles en fonction de l'erreur
types que vous recherchez et le niveau de détail dont vous avez besoin pour les analyser. Pour
exemple, si vous ne vous intéressez qu'aux erreurs de fuite de mémoire, il suffit d'enregistrer
les traces de la pile d'allocation.

Chez aucun, aucune trace de pile n'est enregistrée pour les opérations malloc et free. Si votre
le programme alloue beaucoup de blocs et/ou alloue/libère de nombreuses piles différentes
traces, cela peut réduire considérablement le processeur et/ou la mémoire requise. Bien sûr, peu
les détails seront signalés pour les erreurs liées aux blocs de tas.

Notez qu'une fois qu'une trace de pile est enregistrée, Valgrind garde la trace de pile en mémoire
même s'il n'est référencé par aucun bloc. Certains programmes (par exemple, récursif
algorithmes) peut générer un grand nombre de traces de pile. Si Valgrind utilise trop
mémoire dans de telles circonstances, vous pouvez réduire la mémoire requise avec les options
--keep-stacktraces et/ou en utilisant une valeur plus petite pour l'option --num-appelants.

--freelist-vol= [défaut: 20000000]
Lorsque le programme client libère de la mémoire en utilisant gratuitement (en C) ou supprimer (C++), cette mémoire
n'est pas immédiatement disponible pour une réaffectation. Au lieu de cela, il est marqué
inaccessibles et placés dans une file de blocs libérés. Le but est de différer aussi longtemps que
possible le moment où la mémoire libérée revient en circulation. Cette
augmente les chances que Memcheck puisse détecter les accès invalides aux blocs
pendant un certain temps après leur libération.

Cette option spécifie la taille totale maximale, en octets, des blocs dans la file d'attente.
La valeur par défaut est de vingt millions d'octets. Augmenter cela augmente le montant total
de mémoire utilisée par Memcheck mais peut détecter des utilisations invalides de blocs libérés qui
sinon passer inaperçu.

--freelist-big-blocks= [défaut: 1000000]
Lors de la mise à disposition de blocs de la file d'attente de blocs libérés pour une réallocation,
Memcheck fera recirculer en priorité les blocs de taille supérieure ou égale à
--freelist-gros-blocs. Cela garantit que la libération de gros blocs (en particulier la libération
blocs plus gros que --freelist-vol) n'entraîne pas immédiatement une recirculation de
tous (ou beaucoup) les petits blocs de la liste libre. En d'autres termes, cette option
augmente la probabilité de découvrir des pointeurs pendants pour les "petits" blocs, même
lorsque de gros blocs sont libérés.

La définition d'une valeur de 0 signifie que tous les blocs sont remis en circulation dans un ordre FIFO.

--workaround-gcc296-bugs= [défaut: non]
Lorsqu'il est activé, supposez que lit et écrit à une petite distance en dessous du pointeur de pile
sont dus à des bogues dans GCC 2.96, et ne les rapporte pas. La "petite distance" est de 256
octets par défaut. Notez que GCC 2.96 est le compilateur par défaut sur certains anciens Linux
distributions (RedHat 7.X) et vous devrez peut-être utiliser cette option. Ne l'utilisez pas si
vous n'êtes pas obligé de le faire, car cela peut faire oublier de vraies erreurs. Une meilleure alternative
est d'utiliser un GCC plus récent dans lequel ce bogue est corrigé.

Vous devrez peut-être également utiliser cette option lorsque vous travaillez avec GCC 3.X ou 4.X sur 32 bits
PowerPC Linux. C'est parce que GCC génère du code qui accède occasionnellement ci-dessous
le pointeur de pile, en particulier pour les conversions en virgule flottante vers/depuis un entier. Cette
est en violation de la spécification PowerPC ELF 32 bits, qui ne prévoit aucune
emplacements sous le pointeur de pile pour être accessibles.

--show-mismatched-frees= [défaut: Oui]
Lorsqu'il est activé, Memcheck vérifie que les blocs de tas sont désalloués à l'aide d'une fonction qui
correspond à la fonction d'attribution. c'est-à-dire qu'il s'attend gratuitement être utilisé pour désallouer
blocs alloués par malloc, effacer pour les blocs alloués par nouvelle et effacer[] pour
blocs alloués par Nouveau[]. Si une incompatibilité est détectée, une erreur est signalée. C'est dans
général important car dans certains environnements, la libération avec une fonction non correspondante
peut provoquer des plantages.

Il existe cependant un scénario où de telles inadéquations ne peuvent être évitées. C'est alors que le
l'utilisateur fournit des implémentations de nouvelle/Nouveau[] cet appel malloc et des effacer/effacer[]
cet appel gratuitement, et ces fonctions sont asymétriquement alignées. Par exemple, imaginez
qui effacer[] est aligné mais Nouveau[] n'est pas. Le résultat est que Memcheck "voit" tout
effacer[] appels en tant qu'appels directs vers gratuitement, même lorsque la source du programme ne contient aucun
appels incompatibles.

Cela provoque de nombreux rapports d'erreurs déroutants et non pertinents.
--show-mismatched-frees=non désactive ces contrôles. Il n'est généralement pas conseillé de
désactivez-les, cependant, car vous risquez de manquer de vraies erreurs en conséquence.

--ignore-ranges=0xPP-0xQQ[,0xRR-0xSS]
Toutes les plages répertoriées dans cette option (et plusieurs plages peuvent être spécifiées, séparées par
virgules) sera ignoré par la vérification d'adressabilité de Memcheck.

--malloc-fill=
Remplit les blocs alloués par malloc, new, etc, mais pas par calloc, avec le spécifié
octet. Cela peut être utile lorsque vous essayez de résoudre d'obscurs problèmes de corruption de mémoire.
La zone allouée est toujours considérée par Memcheck comme non définie -- cette option uniquement
affecte son contenu. Noter que --malloc-fill n'affecte pas un bloc de mémoire lorsque
il sert d'argument aux requêtes client VALGRIND_MEMPOOL_ALLOC ou
VALGRIND_MALLOCLIKE_BLOCK.

--free-fill=
Remplit les blocs libérés par free, delete, etc, avec la valeur d'octet spécifiée. Cela peut être
utile lorsque vous essayez de se débarrasser d'obscurs problèmes de corruption de mémoire. La zone libérée est
toujours considéré par Memcheck comme non valide pour l'accès -- cette option n'affecte que son
Contenu. Noter que --remplissage libre n'affecte pas un bloc de mémoire lorsqu'il est utilisé comme
argument aux demandes client VALGRIND_MEMPOOL_FREE ou VALGRIND_FREELIKE_BLOCK.

CACHÉGRIND OPTIONS

--I1= , , taille>
Spécifiez la taille, l'associativité et la taille de ligne du cache d'instructions de niveau 1.

--D1= , , taille>
Spécifiez la taille, l'associativité et la taille de ligne du cache de données de niveau 1.

--LL= , , taille>
Spécifiez la taille, l'associativité et la taille de ligne du cache de dernier niveau.

--cache-sim=non|oui [Oui]
Active ou désactive la collecte d'accès au cache et le nombre d'échecs.

--branch-sim=non|oui [non]
Active ou désactive la collecte d'instructions de branchement et le nombre d'erreurs de prédiction. Par
par défaut, ceci est désactivé car il ralentit Cachegrind d'environ 25 %. Noter que
vous ne pouvez pas spécifier --cache-sim=non et --branch-sim=non ensemble, car cela laisserait
Cachegrind sans aucune information à collecter.

--cachegrind-out-file=
Écrivez les données du profil dans un fichier plutôt que dans le fichier de sortie par défaut,
cachegrind.out. . Les %p et %q les spécificateurs de format peuvent être utilisés pour intégrer le processus
ID et/ou le contenu d'une variable d'environnement dans le nom, comme c'est le cas pour le
option de base --fichier journal.

APPELGRIND OPTIONS

--callgrind-out-file=
Écrivez les données du profil dans un fichier plutôt que dans le fichier de sortie par défaut,
callgrind.out. . Les %p et %q les spécificateurs de format peuvent être utilisés pour intégrer le processus
ID et/ou le contenu d'une variable d'environnement dans le nom, comme c'est le cas pour le
option de base --fichier journal. Lorsque plusieurs dumps sont effectués, le nom du fichier est modifié
plus loin; voir ci-dessous.

--dump-line= [défaut: Oui]
Cela spécifie que le comptage d'événements doit être effectué à la granularité de la ligne source.
Cela permet l'annotation de source pour les sources qui sont compilées avec des informations de débogage
(-g).

--dump-instr= [défaut: non]
Cela spécifie que le comptage d'événements doit être effectué à la granularité par instruction.
Cela permet l'annotation du code d'assemblage. Actuellement, les résultats ne peuvent être affichés que
par KCachegrind.

--compress-strings= [défaut: Oui]
Cette option influence le format de sortie des données de profil. Il précise si
les chaînes (noms de fichiers et de fonctions) doivent être identifiées par des nombres. Cela rétrécit le
fichier, mais le rend plus difficile à lire pour les humains (ce qui n'est recommandé dans aucun
Cas).

--compress-pos= [défaut: Oui]
Cette option influence le format de sortie des données de profil. Il précise si
les positions numériques sont toujours spécifiées en tant que valeurs absolues ou peuvent être
par rapport aux numéros précédents. Cela réduit la taille du fichier.

--combine-dumps= [défaut: non]
Lorsque cette option est activée, lorsque plusieurs parties de données de profil doivent être générées, ces parties sont
ajouté au même fichier de sortie. Non recommandé.

--dump-every-bb= [défaut: 0, jamais]
Vider les données de profil tous les compter blocs de base. Si un vidage est nécessaire est seulement vérifié
lorsque le planificateur interne de Valgrind est exécuté. Par conséquent, le réglage minimum utile est
environ 100000 64. Le nombre est une valeur de XNUMX bits pour permettre de longues périodes de vidage.

--dump-before=
Vider en entrant fonction.

--zero-before=
Zéro tous les frais en entrant fonction.

--dump-after=
Jeter en partant fonction.

--instr-atstart= [défaut: Oui]
Spécifiez si vous souhaitez que Callgrind démarre la simulation et le profilage depuis le début de
le programme. Lorsqu'il est défini sur non, Callgrind ne pourra collecter aucune information,
appels compris, mais il aura au maximum un ralentissement d'environ 4, ce qui est le minimum
Valgrind au-dessus. L'instrumentation peut être activée de manière interactive via callgrind_control
-je sur.

Notez que le graphe d'appels résultant ne contiendra très probablement pas principal, mais sera
contiennent toutes les fonctions exécutées après l'activation de l'instrumentation. Instrumentation
peut également être activé/désactivé par programmation. Voir le fichier d'inclusion Callgrind callgrind.h
pour la macro que vous devez utiliser dans votre code source.

Pour la simulation de cache, les résultats seront moins précis lors de la mise en marche de l'instrumentation
plus tard dans l'exécution du programme, car le simulateur démarre avec un cache vide à ce moment-là.
Activez la collecte d'événements plus tard pour faire face à cette erreur.

--collect-atstart= [défaut: Oui]
Spécifiez si la collecte d'événements est activée au début de l'exécution du profil.

Pour ne regarder que des parties de votre programme, vous avez deux possibilités :

1. Mettez à zéro les compteurs d'événements avant d'entrer dans la partie de programme que vous souhaitez profiler et videz
l'événement compte sur un fichier après avoir quitté cette partie de programme.

2. Activez/désactivez l'état de collecte au besoin pour ne voir que les compteurs d'événements se produire
à l'intérieur de la partie de programme que vous souhaitez profiler.

La deuxième option peut être utilisée si la partie de programme que vous souhaitez profiler s'appelle plusieurs
fois. L'option 1, c'est-à-dire créer beaucoup de vidages n'est pas pratique ici.

L'état de collecte peut être basculé à l'entrée et à la sortie d'une fonction donnée avec l'option
--toggle-collecte. Si vous utilisez cette option, l'état de collecte doit être désactivé au
début. Notez que la spécification de --toggle-collecte définit implicitement
--collect-state=non.

L'état de la collecte peut également être basculé en insérant la demande du client
CALLGRIND_TOGGLE_COLLECT ; aux positions de code nécessaires.

--toggle-collect=
Basculer la collecte à l'entrée/sortie de fonction.

--collect-jumps= [défaut: non]
Ceci spécifie si les informations pour les sauts (conditionnels) doivent être collectées. Comme
ci-dessus, callgrind_annotate n'est actuellement pas en mesure de vous montrer les données. Vous devez utiliser
KCachegrind pour obtenir des flèches de saut dans le code annoté.

--collect-systime= [défaut: non]
Ceci spécifie si les informations sur les heures d'appel système doivent être collectées.

--collect-bus= [défaut: non]
Ceci spécifie si le nombre d'événements de bus globaux exécutés doit être collecté.
Le type d'événement "Ge" est utilisé pour ces événements.

--cache-sim= [défaut: non]
Spécifiez si vous souhaitez effectuer une simulation de cache complète. Par défaut, seule l'instruction lue
les accès seront comptés ("Ir"). Avec la simulation de cache, d'autres compteurs d'événements sont
activé : le cache manque sur les lectures d'instructions ("I1mr"/"ILmr"), les accès en lecture de données ("Dr")
et échecs de cache associés ("D1mr"/"DLmr"), accès en écriture de données ("Dw") et cache associé
manque ("D1mw"/"DLmw"). Pour plus d'informations, voir Cachegrind : un cache et une branche-
profileur de prédiction.

--branche-sim= [défaut: non]
Spécifiez si vous souhaitez effectuer une simulation de prédiction de branche. D'autres compteurs d'événements sont
enabled : nombre de branches conditionnelles exécutées et d'échecs de prédicteur associés
("Bc"/"Bcm"), sauts indirects exécutés et échecs associés du prédicteur d'adresse de saut
("Bi"/"Bim").

HELGRIND OPTIONS

--free-is-write=non|oui [défaut: non]
Lorsqu'il est activé (pas par défaut), Helgrind traite la libération de la mémoire du tas comme si le
la mémoire a été écrite juste avant le libre. Cela expose les races où la mémoire est
référencé par un thread, et libéré par un autre, mais il n'y a pas d'observable
événement de synchronisation pour s'assurer que la référence se produit avant le free.

Cette fonctionnalité est nouvelle dans Valgrind 3.7.0 et est considérée comme expérimentale. Il est
non activé par défaut car son interaction avec les répartiteurs de mémoire personnalisés n'est pas
bien compris à l'heure actuelle. Les commentaires des utilisateurs sont les bienvenus.

--track-lockorders=non|oui [défaut: Oui]
Lorsqu'il est activé (valeur par défaut), Helgrind effectue une vérification de la cohérence de l'ordre des verrous. Pour
certains programmes bogués, le grand nombre d'erreurs d'ordre de verrouillage signalées peut devenir
ennuyeux, surtout si vous ne vous intéressez qu'aux erreurs de course. Vous pouvez donc
trouver utile de désactiver la vérification de l'ordre des verrous.

--history-level=aucun|environ|complet [défaut: complet]
--history-level=complet (valeur par défaut) fait que Helgrind collecte suffisamment d'informations sur
"anciens" accès qu'il peut produire deux traces de pile dans un rapport de course - à la fois la pile
trace pour l'accès actuel et la trace pour l'accès plus ancien en conflit. À
limiter l'utilisation de la mémoire, les "anciens" accès traces de la pile sont limités à un maximum de 8 entrées,
même si --num-appelants la valeur est plus grande.

La collecte de telles informations est coûteuse en vitesse et en mémoire, en particulier pour
programmes qui effectuent de nombreux événements de synchronisation inter-thread (verrouillages, déverrouillages, etc.).
Sans ces informations, il est plus difficile de traquer les causes profondes des races.
Néanmoins, vous n'en aurez peut-être pas besoin dans les situations où vous souhaitez simplement vérifier le
présence ou absence de races, par exemple, lors d'un test de régression d'un
programme auparavant sans course.

--history-level=aucun est l'extrême opposé. Cela oblige Helgrind à ne collecter aucun
informations sur les accès précédents. Cela peut être considérablement plus rapide que
--history-level=complet.

--history-level=environ offre un compromis entre ces deux extrêmes. Cela implique
Helgrind pour afficher une trace complète pour l'accès ultérieur, et des informations approximatives
concernant l'accès antérieur. Cette information approximative se compose de deux piles, et
il est garanti que l'accès antérieur s'est produit quelque part entre les points du programme
désigné par les deux piles. Ce n'est pas aussi utile que d'afficher la pile exacte pour le
accès précédent (comme --history-level=complet fait), mais c'est mieux que rien, et c'est
est presque aussi rapide que --history-level=aucun.

--conflict-cache-size=N [défaut: 1000000]
Ce drapeau n'a d'effet qu'à --history-level=complet.

Les informations sur les "anciens" accès conflictuels sont stockées dans un cache de taille limitée,
avec une gestion de style LRU. Ceci est nécessaire car il n'est pas pratique de stocker un
trace de pile pour chaque accès à la mémoire effectué par le programme. Information historique
sur les emplacements pas récemment accédés est périodiquement rejeté, pour libérer de l'espace dans le
cache

Cette option contrôle la taille du cache, en termes de nombre de mémoires différentes
adresses pour lesquelles des informations d'accès conflictuelles sont stockées. Si tu trouves ça
Helgrind affiche des erreurs de course avec un seul stack au lieu des deux attendus
piles, essayez d'augmenter cette valeur.

La valeur minimale est de 10,000 30,000,000 et la valeur maximale de XNUMX XNUMX XNUMX (trente fois la valeur par défaut
valeur). Augmenter la valeur de 1 augmente les besoins en mémoire de Helgrind de très
environ 100 octets, donc la valeur maximale consommera facilement trois gigaoctets supplémentaires environ
de la mémoire.

--check-stack-refs=non|oui [défaut: Oui]
Par défaut, Helgrind vérifie tous les accès à la mémoire de données effectués par votre programme. Ce drapeau
vous permet d'ignorer la vérification des accès aux piles de threads (variables locales). Ceci peut
améliorer les performances, mais se fait au prix de courses manquantes sur les données allouées par pile.

--ignore-thread-creation= [défaut: non]
Contrôle si toutes les activités pendant la création du thread doivent être ignorées. Par défaut
activé uniquement sur Solaris. Solaris offre un débit, un parallélisme et un
évolutivité que les autres systèmes d'exploitation, au prix d'un verrouillage plus fin
activité. Cela signifie par exemple que lorsqu'un fil est créé sous glibc, un seul
big lock est utilisé pour toutes les configurations de threads. Solaris libc utilise plusieurs verrous à grain fin
et le fil créateur reprend ses activités dès que possible, laissant par exemple
pile et séquence de configuration TLS au thread créé. Cette situation confond Helgrind
car il suppose qu'il y a un faux ordre en place entre le créateur et le créé
fil; et par conséquent, de nombreux types de conditions de concurrence dans l'application ne seraient pas
signalé. Pour éviter un tel ordre erroné, cette option de ligne de commande est définie sur oui par
par défaut sur Solaris. Toute activité (chargements, magasins, demandes clients) est donc ignorée
pendant:

· appel pthread_create() dans le thread créateur

· phase de création de thread (stack et configuration TLS) dans le thread créé

De plus, la nouvelle mémoire allouée lors de la création du fil n'est pas suivie, c'est-à-dire les rapports de course
y est supprimé. DRD fait implicitement la même chose. Ceci est nécessaire car
Solaris libc met en cache de nombreux objets et les réutilise pour différents threads et cela
confond Helgrind.

DRD OPTIONS

--check-stack-var= [défaut: non]
Contrôle si DRD détecte les courses de données sur les variables de pile. Vérification des variables de pile
est désactivé par défaut car la plupart des programmes ne partagent pas les variables de pile sur
threads.

--exclusive-threshold= [défaut: désactivé]
Imprimer un message d'erreur si un mutex ou un verrou d'écriture a été maintenu plus longtemps que le temps imparti
spécifié en millisecondes. Cette option permet de détecter les conflits de verrouillage.

--join-list-vol= [défaut: 10]
Les courses de données qui se produisent entre une instruction à la fin d'un thread et un autre thread
peut être manquée si les informations d'accès à la mémoire sont supprimées immédiatement après qu'un thread a
été rejoint. Cette option permet de spécifier pour combien de mémoire de threads joints
les informations d'accès doivent être conservées.

--first-race-only= [défaut: non]
S'il faut signaler uniquement la première course de données qui a été détectée sur un emplacement mémoire
ou toutes les courses de données qui ont été détectées sur un emplacement mémoire.

--free-is-write= [défaut: non]
S'il faut signaler les courses entre l'accès à la mémoire et la libération de la mémoire. Activer ceci
L'option peut ralentir légèrement l'exécution de DRD. Remarques:

· N'activez pas cette option lors de l'utilisation d'allocateurs de mémoire personnalisés qui utilisent le
VG_USERREQ__MALLOCLIKE_BLOCK et VG_USERREQ__FREELIKE_BLOCK car cela
entraîner des faux positifs.

· N'activez pas cette option lors de l'utilisation d'objets à référence comptée car cela
entraîner des faux positifs, même lorsque ce code a été correctement annoté avec
ANNOTATE_HAPPENS_BEFORE et ANNOTATE_HAPPENS_AFTER. Voir par exemple la sortie du
commande suivante pour un exemple : valgrind --tool=drd --free-is-write=yes
drd/tests/annotate_smart_pointer.

--report-signal-unlocked= [défaut: Oui]
S'il faut signaler les appels à pthread_cond_signal et pthread_cond_broadcast où le
mutex associé au signal via pthread_cond_wait or
pthread_cond_timed_waitn'est pas verrouillé au moment où le signal est envoyé. Envoi d'un signal
sans tenir un verrou sur le mutex associé est une erreur de programmation courante qui peut
provoquer des conditions de course subtiles et un comportement imprévisible. Il existe des rares
modèles de synchronisation cependant où il est sûr d'envoyer un signal sans tenir un
verrouiller le mutex associé.

--segment-fusion= [défaut: Oui]
Contrôle la fusion des segments. La fusion de segments est un algorithme pour limiter l'utilisation de la mémoire du
algorithme de détection de course de données. La désactivation de la fusion de segments peut améliorer la précision de
les soi-disant « autres segments » affichés dans les rapports de course mais peuvent également déclencher une sortie
d'erreur de mémoire.

--segment-merging-interval= [défaut: 10]
N'effectuez la fusion de segments qu'une fois que le nombre spécifié de nouveaux segments a été
créé. Il s'agit d'une option de configuration avancée qui permet de choisir si
minimisez l'utilisation de la mémoire de DRD en choisissant une valeur faible ou en laissant DRD s'exécuter plus rapidement en
en choisissant une valeur légèrement supérieure. La valeur optimale de ce paramètre dépend de la
programme en cours d'analyse. La valeur par défaut fonctionne bien pour la plupart des programmes.

--shared-threshold= [défaut: désactivé]
Imprimer un message d'erreur si un verrou de lecteur a été maintenu plus longtemps que la durée spécifiée
(en millisecondes). Cette option permet de détecter les conflits de verrouillage.

--show-confl-seg= [défaut: Oui]
Afficher les segments en conflit dans les rapports de course. Étant donné que ces informations peuvent aider à trouver le
cause d'une course aux données, cette option est activée par défaut. La désactivation de cette option rend
la sortie de DRD plus compacte.

--show-stack-usage= [défaut: non]
Utilisation de la pile d'impression au moment de la sortie du thread. Lorsqu'un programme crée un grand nombre de
threads, il devient important de limiter la quantité de mémoire virtuelle allouée pour
piles de fils. Cette option permet d'observer combien de mémoire de pile a été
utilisé par chaque thread du programme client. Remarque : l'outil DRD lui-même alloue certains
données temporaires sur la pile de threads client. L'espace nécessaire à ces données temporaires
doit être alloué par le programme client lorsqu'il alloue de la mémoire de pile, mais n'est pas
inclus dans l'utilisation de la pile rapportée par DRD.

--ignore-thread-creation= [défaut: non]
Contrôle si toutes les activités pendant la création du thread doivent être ignorées. Par défaut
activé uniquement sur Solaris. Solaris offre un débit, un parallélisme et un
évolutivité que les autres systèmes d'exploitation, au prix d'un verrouillage plus fin
activité. Cela signifie par exemple que lorsqu'un fil est créé sous glibc, un seul
big lock est utilisé pour toutes les configurations de threads. Solaris libc utilise plusieurs verrous à grain fin
et le fil créateur reprend ses activités dès que possible, laissant par exemple
pile et séquence de configuration TLS au thread créé. Cette situation embrouille DRD car elle
suppose qu'il y a un faux ordre en place entre le créateur et le fil créé ; et
par conséquent, de nombreux types de conditions de concurrence dans l'application ne seraient pas signalés. À
empêcher un tel ordre erroné, cette option de ligne de commande est définie sur oui par défaut sur
Solaris. Toute activité (chargements, magasins, demandes clients) est donc ignorée pendant :

· appel pthread_create() dans le thread créateur

· phase de création de thread (stack et configuration TLS) dans le thread créé

--trace-addr= [défaut: rien]
Suivez toutes les activités de chargement et de stockage pour l'adresse spécifiée. Cette option peut être
spécifié plus d'une fois.

--ptrace-addr= [défaut: rien]
Tracez toutes les activités de chargement et de stockage pour l'adresse spécifiée et continuez à le faire même
après que la mémoire à cette adresse a été libérée et réaffectée.

--trace-alloc= [défaut: non]
Tracez toutes les allocations et désallocations de mémoire. Peut produire une énorme quantité de sortie.

--trace-barrière= [défaut: non]
Tracez toutes les activités de barrière.

--trace-cond= [défaut: non]
Trace toute l'activité des variables de condition.

--trace-fork-join= [défaut: non]
Tracez toutes les créations de threads et tous les événements de terminaison de threads.

--trace-hb= [défaut: non]
Trace l'exécution de ANNOTATE_HAPPENS_BEFORE(), ANNOTATE_HAPPENS_AFTER() et
demandes du client ANNOTATE_HAPPENS_DONE().

--trace-mutex= [défaut: non]
Trace toutes les activités mutex.

--trace-rwlock= [défaut: non]
Tracez toutes les activités de verrouillage de lecteur-écrivain.

--trace-semaphore= [défaut: non]
Trace toute l'activité des sémaphores.

MASSIF OPTIONS

--heap= [défaut: Oui]
Spécifie si le profilage de tas doit être effectué.

--heap-admin= [défaut: 8]
Si le profilage de tas est activé, donne le nombre d'octets administratifs par bloc à
utilisation. Il doit s'agir d'une estimation de la moyenne, car elle peut varier. Par exemple, le
l'allocateur utilisé par la glibc sous Linux nécessite entre 4 et 15 octets par bloc,
en fonction de divers facteurs. Cet allocator nécessite également un espace d'administration pour libérer
blocs, mais Massif ne peut pas en tenir compte.

--piles= [défaut: non]
Spécifie si le profilage de pile doit être effectué. Cette option ralentit Massif
grandement, et est donc désactivé par défaut. Notez que Massif suppose que la pile principale a
taille zéro au démarrage. Ce n'est pas vrai, mais faire autrement avec précision est difficile.
De plus, commencer à zéro indique mieux la taille de la partie de la pile principale
qu'un programme utilisateur a réellement le contrôle.

--pages-as-heap= [défaut: non]
Dit à Massif de profiler la mémoire au niveau de la page plutôt qu'au bloc malloc'd
niveau. Voir ci-dessus pour les détails.

--profondeur= [défaut: 30]
Profondeur maximale des arbres d'allocation enregistrés pour les instantanés détaillés. l'augmenter
fera fonctionner Massif un peu plus lentement, utilisera plus de mémoire et produira une sortie plus importante
fichiers.

--alloc-fn=
Les fonctions spécifiées avec cette option seront traitées comme si elles étaient un tas
fonction d'allocation telle que malloc. Ceci est utile pour les fonctions qui sont des wrappers pour
malloc or nouvelle, ce qui peut remplir les arbres d'allocation d'informations inintéressantes.
Cette option peut être spécifiée plusieurs fois sur la ligne de commande, pour nommer plusieurs
fonctions.

Notez que la fonction nommée ne sera traitée de cette façon que si c'est l'entrée supérieure dans un
trace de pile, ou juste en dessous d'une autre fonction traitée de cette façon. Par exemple, si vous avez
une fonction malloc1 qui enveloppe malloc et malloc2 qui enveloppe malloc1, en précisant simplement
--alloc-fn=malloc2 n'aura aucun effet. Vous devez spécifier --alloc-fn=malloc1 as
bien. C'est un peu gênant, mais la raison en est que la vérification de l'allocation
fonctions est lente, et cela fait gagner beaucoup de temps si Massif peut arrêter de regarder dans les
empiler les entrées de trace dès qu'il en trouve une qui ne correspond pas plutôt que d'avoir à
continuer à travers toutes les entrées.

Notez que les noms C++ sont démêlés. Notez également que les noms C++ surchargés doivent être écrits
en entier. Des guillemets simples peuvent être nécessaires pour empêcher le shell de les séparer.
Par exemple :

--alloc-fn='operator new(unsigned, std::nothrow_t const&)'

--ignore-fn=
Toute allocation directe de tas (c'est-à-dire un appel à malloc, nouvelle, etc, ou un appel à une fonction
nommé par un --alloc-fn option) qui se produit dans une fonction spécifiée par cette option sera
Etre ignoré. Ceci est surtout utile à des fins de test. Cette option peut être spécifiée
plusieurs fois sur la ligne de commande, pour nommer plusieurs fonctions.

Toutes réallouer d'un bloc ignoré sera également ignoré, même si le réallouer l'appel fait
ne se produisent pas dans une fonction ignorée. Cela évite la possibilité de tailles de tas négatives
si les blocs ignorés sont réduits avec réallouer.

Les règles d'écriture des noms de fonction C++ sont les mêmes que pour --alloc-fn au dessus.

--seuil= [défaut: 1.0]
Seuil de signification pour les allocations de tas, en pourcentage de la taille totale de la mémoire.
Les entrées de l'arbre d'allocation qui représentent moins que cela seront agrégées. Noter que
cela doit être spécifié en tandem avec l'option ms_print du même nom.

--peak-inexactitude= [défaut: 1.0]
Massif n'enregistre pas nécessairement le pic d'allocation mémoire globale réelle ; par
par défaut, il enregistre un pic uniquement lorsque la taille globale de l'allocation de mémoire dépasse le
pic précédent d'au moins 1.0 %. C'est parce qu'il peut y avoir de nombreuses allocations locales
des pics en cours de route, et faire un instantané détaillé pour chacun serait coûteux
et inutiles, car tous sauf un seront jetés plus tard. Cette imprécision peut être
changé (même à 0.0%) via cette option, mais Massif fonctionnera considérablement plus lentement car le
nombre approche de zéro.

--time-unit= [défaut: i]
Unité de temps utilisée pour le profilage. Il y a trois possibilités : mode d'emploi
exécuté (i), ce qui est bon dans la plupart des cas ; temps réel (horloge murale) (ms, c'est-à-dire
millisecondes), ce qui est parfois utile ; et octets alloués/désalloués sur le tas
et/ou pile (B), ce qui est utile pour les programmes à très court terme et pour tester
fins, car il est le plus reproductible sur différentes machines.

--detailed-freq= [défaut: 10]
Fréquence des instantanés détaillés. Avec --fréquence-détaillée=1, chaque instantané est détaillé.

--max-instantanés= [défaut: 100]
Le nombre maximum d'instantanés enregistrés. S'il est défini sur N, pour tous les programmes sauf très
courts, le nombre final d'instantanés sera compris entre N/2 et N.

--massif-out-file= [défaut: massif.out.%p]
Écrivez les données du profil dans un fichier plutôt que dans le fichier de sortie par défaut,
massif.out. . Les %p et %q les spécificateurs de format peuvent être utilisés pour intégrer l'ID de processus
et/ou le contenu d'une variable d'environnement dans le nom, comme c'est le cas pour le
option de base --fichier journal.

SGCHECK OPTIONS

Il n'existe actuellement aucune option de ligne de commande spécifique à SGCheck.

BBV OPTIONS

--bb-out-file= [défaut: bb.out.%p]
Cette option sélectionne le nom du fichier vectoriel du bloc de base. Les %p et %q le format
les spécificateurs peuvent être utilisés pour intégrer l'ID de processus et/ou le contenu d'un environnement
variable dans le nom, comme c'est le cas pour l'option core --fichier journal.

--pc-out-file= [défaut: sortie pc.%p]
Cette option sélectionne le nom du fichier PC. Ce fichier contient les adresses des compteurs de programme
et des informations sur le nom de la fonction pour les différents blocs de base. Cela peut être utilisé en conjonction
avec le fichier vectoriel de bloc de base pour avancer rapidement via les noms de fonction au lieu de simplement
l'instruction compte. Les %p et %q les spécificateurs de format peuvent être utilisés pour intégrer le processus
ID et/ou le contenu d'une variable d'environnement dans le nom, comme c'est le cas pour le
option de base --fichier journal.

--intervalle-taille= [défaut: 100000000]
Cette option sélectionne la taille de l'intervalle à utiliser. La valeur par défaut est 100 millions
instructions, qui est une valeur couramment utilisée. D'autres tailles peuvent être utilisées ; plus petite
Les intervalles peuvent aider les programmes avec des phases plus fines. Cependant la taille de l'intervalle est plus petite
peut entraîner des problèmes de précision en raison des effets d'échauffement (lors de l'avance rapide des différents
les éléments architecturaux ne seront pas initialisés et il faudra un certain nombre de
instructions avant qu'elles ne "se réchauffent" à l'état où une simulation complète se trouverait sans
l'avance rapide. Les grandes tailles d'intervalle ont tendance à atténuer cela.)

--instr-count-only [défaut: non]
Cette option indique à l'outil d'afficher uniquement les totaux du nombre d'instructions et de ne pas
générer le fichier vectoriel du bloc de base réel. Ceci est utile pour le débogage et pour
collecte d'informations sur le nombre d'instructions sans générer le grand vecteur de bloc de base
fichiers.

LAQUAIS OPTIONS

--basic-count= [défaut: Oui]
Lorsqu'il est activé, Lackey imprime les statistiques et informations suivantes sur le
exécution du programme client :

1. Le nombre d'appels à la fonction spécifié par le --nomfn option (la valeur par défaut
est principal). Si le programme a vu ses symboles supprimés, le compte sera toujours
zéro.

2. Le nombre de branches conditionnelles rencontrées et le nombre et la proportion de
ceux pris.

3. Le nombre de superblocs entrés et complétés par le programme. Notez qu'en raison de
optimisations effectuées par le JIT, ce n'est pas du tout une valeur précise.

4. Le nombre d'instructions invité (x86, amd64, ppc, etc.) et d'instructions IR
réalisé. IR est la représentation intermédiaire de type RISC de Valgrind via laquelle tous
l'instrumentation est faite.

5. Ratios entre certains de ces comptes.

6. Le code de sortie du programme client.

--detailed-counts= [défaut: non]
Lorsqu'il est activé, Lackey imprime un tableau contenant le nombre de charges, de magasins et d'ALU
opérations, différenciées par leurs types IR. Les types IR sont identifiés par leur IR
nom ("I1", "I8", ... "I128", "F32", "F64" et "V128").

--trace-mem= [défaut: non]
Lorsqu'il est activé, Lackey imprime la taille et l'adresse de presque tous les accès mémoire effectués par
le programme. Voir les commentaires en haut du fichier lackey/lk_main.c pour plus de détails
sur le format de sortie, son fonctionnement et les inexactitudes dans la trace des adresses. Noter
que cette option produit d'immenses quantités de sortie.

--trace-superblocs= [défaut: non]
Lorsqu'il est activé, Lackey imprime l'adresse de chaque superbloc (une seule entrée,
sortie multiple, morceau de code linéaire) exécuté par le programme. Il s'agit principalement de
intérêt pour les développeurs de Valgrind. Voir les commentaires en haut du fichier
lackey/lk_main.c pour plus de détails sur le format de sortie. Notez que cette option produit
de grandes quantités de sortie.

--fnname= [défaut: principale]
Modifie la fonction pour laquelle les appels sont comptés lorsque --basic-count=oui est spécifié.

Utilisez valgrind en ligne en utilisant les services onworks.net