Valgrind

PROGRAMM:

NAME/FUNKTION

valgrind - eine Suite von Tools zum Debuggen und Profiling von Programmen

ZUSAMMENFASSUNG

Valgrind [Valgrind-Optionen] [dein-programm] [Ihre-Programm-Optionen]

BESCHREIBUNG

Valgrind ist ein flexibles Programm zum Debuggen und Profilieren von ausführbaren Linux-Dateien. Es besteht
eines Kerns, der eine synthetische CPU in Software bereitstellt, und eine Reihe von Debugging- und
Profilierungswerkzeuge. Die Architektur ist modular, sodass neue Tools einfach erstellt werden können und
ohne die bestehende Struktur zu stören.

Einige der unten beschriebenen Optionen funktionieren mit allen Valgrind-Werkzeugen, andere nur mit
ein paar oder eins. Der Abschnitt MEMCHECK-OPTIONEN und die darunter liegenden beschreiben werkzeugspezifische
nach.

Diese Handbuchseite behandelt nur die grundlegende Verwendung und Optionen. Für umfassendere Informationen,
Bitte sehen Sie in der HTML-Dokumentation Ihres Systems nach:
$INSTALL/share/doc/valgrind/html/index.html oder online:
http://www.valgrind.org/docs/manual/index.html.

TOOL SELECTION OPTIONAL

Die wichtigste Option.

--tool= [Ursprünglich: Speichercheck]
Führen Sie das Valgrind-Tool namens . aus Werkzeugname, zB memcheck, cachegrind, callgrind, helgrind,
drd, massiv, lakai, keine, exp-sgcheck, exp-bbv, exp-dhat usw.

BASIC OPTIONAL

Diese Optionen funktionieren mit allen Tools.

-h --help
Hilfe zu allen Optionen anzeigen, sowohl für den Kern als auch für das ausgewählte Werkzeug. Wenn die Option
wiederholt wird es gleichbedeutend mit Geben --help-debug.

--help-debug
Das gleiche wie --help, sondern listet auch Debugging-Optionen auf, die normalerweise nur für
Valgrinds Entwickler.

--Version
Zeigen Sie die Versionsnummer des Valgrind-Kerns an. Tools können eine eigene Version haben
Zahlen. Es gibt ein Schema, um sicherzustellen, dass Tools nur ausgeführt werden, wenn der Kern
Version ist eine, mit der sie bekanntermaßen arbeiten. Dies wurde getan, um die Wahrscheinlichkeit von zu minimieren
seltsame Probleme, die sich aus Inkompatibilitäten der Tool-gegen-Kern-Version ergeben.

-q, --ruhig
Im Hintergrund ausführen und nur Fehlermeldungen ausgeben. Nützlich, wenn Sie eine Regression ausführen
Tests durchführen oder über andere automatisierte Testmaschinen verfügen.

-v, - ausführlich
Seien Sie ausführlicher. Bietet zusätzliche Informationen zu verschiedenen Aspekten Ihres Programms, wie zum Beispiel:
die geladenen Shared Objects, die verwendeten Unterdrückungen, der Fortschritt der Instrumentierung
und Ausführungs-Engines sowie Warnungen vor ungewöhnlichem Verhalten. Wiederholen der Option
erhöht die Ausführlichkeit.

--trace-children= [Ursprünglich: Nein]
Wenn aktiviert, verfolgt Valgrind Subprozesse, die über das exec System
Anruf. Dies ist für Mehrprozessprogramme erforderlich.

Beachten Sie, dass Valgrind in das Kind von a . zurückverfolgt wird Gabel (es wäre schwer, nicht
da Gabel erstellt eine identische Kopie eines Prozesses), daher ist diese Option wohl schlecht
genannt. Die meisten Kinder von Gabel ruft sofort an ruf an exec egyébként.

--trace-children-skip=patt1,patt2,...
Diese Option hat nur eine Wirkung, wenn --trace-children=ja angegeben. Es ermöglicht
einige Kinder übersprungen werden. Die Option verwendet eine durch Kommas getrennte Liste von Mustern für
die Namen der untergeordneten ausführbaren Dateien, die Valgrind nicht verfolgen sollte. Muster können
die Metazeichen einschließen? und *, die die übliche Bedeutung haben.

Dies kann nützlich sein, um uninteressante Äste aus einem Baum von Prozessen zu entfernen
auf Valgrind laufen. Aber Sie sollten vorsichtig sein, wenn Sie es verwenden. Wenn Valgrind die Verfolgung überspringt
in eine ausführbare Datei, es überspringt nicht nur die Verfolgung dieser ausführbaren Datei, sondern überspringt auch
Verfolgen eines der untergeordneten Prozesse dieser ausführbaren Datei. Mit anderen Worten, die Flagge nicht
bewirkt lediglich, dass die Ablaufverfolgung bei den angegebenen ausführbaren Dateien stoppt - es überspringt die Ablaufverfolgung von
gesamte Prozessunterbäume, die in einer der angegebenen ausführbaren Dateien verwurzelt sind.

--trace-children-skip-by-arg=patt1,patt2,...
Dies ist das gleiche wie --trace-children-skip, mit einem Unterschied: die Entscheidung bzgl
ob in einen Kindprozess zurückverfolgt werden soll, wird durch Prüfung der Argumente für das Kind vorgenommen
Prozess statt den Namen seiner ausführbaren Datei.

--child-silent-after-fork= [Ursprünglich: Nein]
Wenn aktiviert, zeigt Valgrind keine Debugging- oder Logging-Ausgabe für das Kind an
Prozess, der sich aus a . ergibt Gabel Anruf. Dies kann die Ausgabe weniger verwirrend machen (obwohl
irreführender) im Umgang mit Prozessen, die Kinder hervorbringen. Es ist besonders
nützlich in Verbindung mit --trace-Kinder=. Die Nutzung dieser Option ist ebenfalls dringend
empfohlen, wenn Sie eine XML-Ausgabe anfordern (--xml=ja), da sonst die XML aus
Kind und Elternteil können verwechselt werden, was es normalerweise nutzlos macht.

--vgdb= [Ursprünglich: Jawohl]
Valgrind wird die "gdbserver"-Funktionalität bereitstellen, wenn --vgdb=ja or --vgdb=voll is
spezifiziert. Dies ermöglicht einem externen GNU GDB-Debugger, Ihr Programm zu kontrollieren und zu debuggen
wenn es auf Valgrind läuft. --vgdb=voll verursacht erhebliche Performance-Overheads, aber
bietet genauere Breakpoints und Watchpoints. Siehe Debuggen Ihres Programms mit
Valgrinds gdbserver und GDB für eine detaillierte Beschreibung.

Wenn der eingebettete gdbserver aktiviert ist, aber derzeit keine gdb verwendet wird, wird die vgdb
Befehlszeilen-Dienstprogramm kann "Monitor-Befehle" von einer Shell an Valgrind senden. Die
Der Valgrind-Kern bietet eine Reihe von Valgrind-Monitorbefehlen. Ein Werkzeug kann optional
stellen werkzeugspezifische Monitorbefehle bereit, die in den werkzeugspezifischen
Kapitel.

--vgdb-error= [Ursprünglich: 999999999]
Verwenden Sie diese Option, wenn der Valgrind gdbserver mit aktiviert ist --vgdb=ja or --vgdb=voll.
Tools, die Fehler melden, warten auf die Meldung von "Anzahl"-Fehlern, bevor sie einfrieren
das Programm und wartet darauf, dass Sie sich mit GDB verbinden. Daraus folgt, dass ein Wert von Null
bewirkt, dass der gdbserver gestartet wird, bevor Ihr Programm ausgeführt wird. Das ist
Wird normalerweise zum Einfügen von GDB-Haltepunkten vor der Ausführung verwendet und funktioniert auch mit Tools
die keine Fehler melden, wie z. B. Massif.

--vgdb-stop-at= [Ursprünglich: keiner]
Verwenden Sie diese Option, wenn der Valgrind gdbserver mit aktiviert ist --vgdb=ja or --vgdb=voll.
Der Valgrind gdbserver wird für jeden Fehler danach aufgerufen --vgdb-Fehler gewesen
berichtet. Sie können den Valgrind gdbserver zusätzlich für andere aufrufen
Ereignisse, die auf eine der folgenden Arten angegeben werden:

· eine durch Kommas getrennte Liste von einem oder mehreren von Anfang wunsch valgrindabexit.

Die Werte Anfang wunsch valgrindabexit jeweils angeben, um gdbserver aufzurufen
bevor Ihr Programm ausgeführt wird, nach der letzten Anweisung Ihres Programms, ein
Valgrind anormaler Ausgang (zB interner Fehler, nicht genügend Speicher, ...).

Hinweis: Anfang und --vgdb-error=0 wird beides dazu führen, dass Valgrind gdbserver aufgerufen wird
bevor Ihr Programm ausgeführt wird. Die --vgdb-error=0 wird zusätzlich dazu führen, dass Ihr
Programm, um bei allen nachfolgenden Fehlern zu stoppen.

· alle um den kompletten Satz zu spezifizieren. Es ist äquivalent zu
--vgdb-stop-at=start,exit,valgrindabexit.

· keine für die leere Menge.

--track-fds= [Ursprünglich: Nein]
Wenn aktiviert, druckt Valgrind beim Beenden oder beim Beenden eine Liste der geöffneten Dateideskriptoren aus
Anfrage über den Befehl gdbserver monitor v.info open_fds. Zusammen mit jeder Datei
Deskriptor wird ein Stack-Backtrace ausgegeben, wo die Datei geöffnet wurde und alle Details
in Bezug auf den Dateideskriptor wie den Dateinamen oder Socket-Details.

--time-stamp= [Ursprünglich: Nein]
Wenn aktiviert, wird jeder Nachricht eine Angabe der abgelaufenen Wanduhr vorangestellt
Zeit seit dem Start, ausgedrückt in Tagen, Stunden, Minuten, Sekunden und Millisekunden.

--log-fd= [Ursprünglich: 2, stderr]
Gibt an, dass Valgrind alle seine Nachrichten an die angegebene Datei senden soll
Beschreibung. Der Standardwert 2 ist der Standardfehlerkanal (stderr). Beachten Sie, dass dies möglicherweise
die eigene Verwendung von stderr durch den Client stören, da die Ausgabe von Valgrind
verschachtelt mit jeder Ausgabe, die der Client an stderr sendet.

--log-file=
Gibt an, dass Valgrind alle seine Nachrichten an die angegebene Datei senden soll. Wenn die
Dateiname leer ist, führt dies zu einem Abbruch. Es gibt drei spezielle Formatbezeichner, die
kann im Dateinamen verwendet werden.

%p wird durch die aktuelle Prozess-ID ersetzt. Dies ist sehr nützlich für Programme, die
mehrere Prozesse aufrufen. WARNUNG: Wenn Sie --trace-children=ja und dein Programm
ruft mehrere Prozesse ODER Ihre Programmgabeln auf, ohne danach exec aufzurufen, und
Sie verwenden diesen Bezeichner nicht (oder den %q Bezeichner unten), die Valgrind-Ausgabe von allen
diese Prozesse werden in eine Datei aufgenommen, möglicherweise durcheinander und möglicherweise unvollständig.

%q{FOO} wird durch den Inhalt der Umgebungsvariablen ersetzt FOO. Wenn der {FOO}
ein Teil fehlerhaft ist, führt dies zu einem Abbruch. Dieser Bezeichner wird selten benötigt, aber sehr
unter bestimmten Umständen nützlich (zB beim Ausführen von MPI-Programmen). Die Idee ist, dass du
Geben Sie eine Variable an, die für jeden Prozess im Job unterschiedlich gesetzt wird, z
BPROC_RANK oder was auch immer in Ihrem MPI-Setup anwendbar ist. Wenn der Name
Umgebungsvariable nicht gesetzt ist, führt sie zu einem Abbruch. Beachten Sie, dass in einigen Shells die {
und } Zeichen müssen möglicherweise mit einem umgekehrten Schrägstrich maskiert werden.

%% wird ersetzt durch %.

Wenn ein % folgt ein beliebiges anderes Zeichen, führt dies zu einem Abbruch.

Wenn der Dateiname einen relativen Dateinamen angibt, wird er in die Initiale des Programms eingefügt
Arbeitsverzeichnis : Dies ist das aktuelle Verzeichnis, als das Programm gestartet wurde
Ausführung nach dem Fork oder nach dem Exec. Wenn es einen absoluten Dateinamen angibt (z.
beginnt mit '/'), dann wird es dort abgelegt.

--log-socket=
Gibt an, dass Valgrind alle seine Nachrichten an den angegebenen Port senden soll
angegebene IP-Adresse. Der Port kann weggelassen werden, in diesem Fall wird Port 1500 verwendet. Wenn eine
Verbindung zum angegebenen Socket kann nicht hergestellt werden, Valgrind greift auf das Schreiben zurück
Ausgabe auf den Standardfehler (stderr). Diese Option soll verwendet werden in
in Verbindung mit dem Valgrind-Listener-Programm. Weitere Details finden Sie im
Kommentar im Handbuch.

FEHLERBEZOGEN OPTIONAL

Diese Optionen werden von allen Tools verwendet, die Fehler melden können, z. B. Memcheck, aber nicht
Cachegrind.

--xml= [Ursprünglich: Nein]
Wenn aktiviert, sind die wichtigen Teile der Ausgabe (z. B. Werkzeugfehlermeldungen) in
XML-Format statt Nur-Text. Außerdem wird die XML-Ausgabe an a
anderen Ausgabekanal als die Klartextausgabe. Daher müssen Sie auch einen verwenden
of --xml-fd, --xml-Datei or --xml-socket um anzugeben, wohin das XML gesendet werden soll.

Weniger wichtige Nachrichten werden weiterhin im Klartext gedruckt, aber weil die XML
Ausgabe und Klartextausgabe werden an verschiedene Ausgabekanäle gesendet (das Ziel von
die Klartextausgabe wird weiterhin gesteuert durch --log-fd, --Logdatei und --log-socket)
das sollte keine probleme machen.

Diese Option soll Werkzeugen das Leben erleichtern, die die Ausgabe von Valgrind als verbrauchen
Eingabe, wie GUI-Frontends. Derzeit funktioniert diese Option mit Memcheck, Helgrind,
DRD und SGcheck. Das Ausgabeformat wird in der Datei angegeben
docs/internals/xml-output-protocol4.txt im Quellbaum für Valgrind 3.5.0 oder
später.

Die empfohlenen Optionen für die Übergabe einer GUI beim Anfordern der XML-Ausgabe sind: --xml=ja
um die XML-Ausgabe zu aktivieren, --xml-Datei um die XML-Ausgabe an eine (vermutlich GUI-selektierte)
Datei, --Logdatei um die Klartextausgabe an eine zweite von der GUI ausgewählte Datei zu senden,
--child-silent-after-fork=jasowie -q um die Klartextausgabe auf kritisch einzuschränken
von Valgrind selbst erstellte Fehlermeldungen. Zum Beispiel Fehler beim Lesen eines angegebenen
Unterdrückungsdatei zählt als kritische Fehlermeldung. Auf diese Weise für ein erfolgreiches
Ausführen der Textausgabedatei ist leer. Aber wenn es nicht leer ist, dann enthält es
wichtige Informationen, auf die der GUI-Benutzer aufmerksam gemacht werden sollte.

--xml-fd= [Ursprünglich: -1, Behinderte]
Gibt an, dass Valgrind seine XML-Ausgabe an den angegebenen Dateideskriptor senden soll.
Es muss in Verbindung mit verwendet werden --xml=ja.

--xml-file=
Gibt an, dass Valgrind seine XML-Ausgabe an die angegebene Datei senden soll. Es muss sein
verwendet in Verbindung mit --xml=ja. Irgendein %p or %q Sequenzen, die im Dateinamen vorkommen
werden genauso erweitert wie für --Logdatei. Siehe die Beschreibung
of --Logdatei .

--xml-socket=
Gibt an, dass Valgrind seine XML-Ausgabe an den angegebenen Port am angegebenen . senden soll
IP Adresse. Es muss in Verbindung mit verwendet werden --xml=ja. Die Argumentationsform ist
das gleiche wie das von --log-socket. Siehe die Beschreibung von --log-socket für ein
Details.

--xml-user-comment=
Bettet eine zusätzliche Benutzerkommentarzeichenfolge am Anfang der XML-Ausgabe ein. Funktioniert nur wenn
--xml=ja angegeben; sonst ignoriert.

--demangle= [Ursprünglich: Jawohl]
Aktivieren/deaktivieren Sie die automatische Entschlüsselung (Decodierung) von C++-Namen. Standardmäßig aktiviert. Wann
aktiviert ist, versucht Valgrind, codierte C++-Namen in etwas zurückzuübersetzen
nähert sich dem Original. Der Demangler behandelt Symbole, die von den g++-Versionen 2.X verstümmelt wurden,
3.X und 4.X.

Eine wichtige Tatsache beim Entmandeln ist, dass in Unterdrückungen erwähnte Funktionsnamen
Dateien sollten in ihrer verstümmelten Form vorliegen. Valgrind zerlegt keine Funktionsnamen, wenn
Suche nach anwendbaren Unterdrückungen, denn sonst würde Unterdrückung zu einer Unterdrückung führen
Dateiinhalt abhängig vom Zustand der Zerkleinerungsmaschinen von Valgrind und auch langsam
Unterdrückungsabgleich nach unten.

--num-callers= [Ursprünglich: 12]
Gibt die maximale Anzahl von Einträgen an, die in Stack-Traces angezeigt werden, die das Programm identifizieren
Standorte. Beachten Sie, dass Fehler nur anhand der vier obersten Funktionsorte zusammengefasst werden
(die Stelle in der aktuellen Funktion und die ihrer drei unmittelbaren Aufrufer). Also das
hat keinen Einfluss auf die Gesamtzahl der gemeldeten Fehler.

Der Höchstwert hierfür ist 500. Beachten Sie, dass bei höheren Einstellungen Valgrind läuft a
etwas langsamer und benötigt etwas mehr Speicher, kann aber bei der Arbeit mit nützlich sein
Programme mit tief verschachtelten Aufrufketten.

--unw-stack-scan-thresh= [Ursprünglich: 0] , --unw-stack-scan-frames= [Ursprünglich:
5]
Stack-Scanning-Unterstützung ist nur auf ARM-Zielen verfügbar.

Diese Flags aktivieren und steuern das Abwickeln des Stapels durch Stapelscannen. Wenn das Normale
Stack-Unwinding-Mechanismen -- Verwendung von Dwarf-CFI-Records und Frame-Pointer-Following
-- fehlschlagen, Stack-Scan kann möglicherweise einen Stack-Trace wiederherstellen.

Beachten Sie, dass das Stapelscannen ein ungenauer, heuristischer Mechanismus ist, der sehr
irreführende Ergebnisse oder gar keine. Es sollte nur in Notfällen verwendet werden, wenn es normal ist
das Abwickeln schlägt fehl, und es ist wichtig, trotzdem Stack-Traces zu haben.

Das Stapelscannen ist eine einfache Technik: Der Abwickler liest Wörter vom Stapel und
versucht zu erraten, welche von ihnen Absenderadressen sein könnten, indem er überprüft, ob sie
Zeigen Sie direkt nach den Anweisungen für ARM- oder Thumb-Aufrufe. Wenn ja, wird das Wort an die angehängt
zurückverfolgen.

Die Hauptgefahr tritt auf, wenn ein Funktionsaufruf zurückkehrt und seine Rückkehradresse hinterlässt
exponiert, und eine neue Funktion wird aufgerufen, aber die neue Funktion überschreibt nicht die alte
die Anschrift. Dies hat zur Folge, dass der Backtrace Einträge für Funktionen enthalten kann
die bereits zurückgekehrt sind, und daher sehr verwirrend sein.

Eine zweite Einschränkung dieser Implementierung besteht darin, dass nur die Seite gescannt wird (4 KB,
normalerweise) mit dem Startstapelzeiger. Wenn die Stapelrahmen groß sind, ist dies
kann dazu führen, dass nur wenige (oder gar keine) im Trace vorhanden sind. Auch wenn du
Pech haben und einen ersten Stapelzeiger am Ende der enthaltenden Seite haben, die
Scan kann alle interessanten Frames verpassen.

Standardmäßig ist das Stapelscannen deaktiviert. Der normale Anwendungsfall besteht darin, danach zu fragen, wenn a
Stacktrace wäre sonst sehr kurz. Um es zu aktivieren, verwenden Sie
--unw-stack-scan-thresh=Nummer. Dies fordert Valgrind auf, das Stapelscannen zu versuchen, um
Stack-Traces "erweitern", die weniger als Anzahl Frames enthalten.

Wenn ein Stapelscannen stattfindet, wird nur maximal die Anzahl der Bilder generiert
angegeben durch --unw-stack-scan-frames. Normalerweise erzeugt das Stapelscannen so viele
Mülleinträge, dass dieser Wert standardmäßig auf einen niedrigen Wert (5) gesetzt ist. Wird auf keinen Fall
ein Stack-Trace, der größer als der von --num-callers angegebene Wert ist, erstellt werden.

--error-limit= [Ursprünglich: Jawohl]
Wenn aktiviert, stoppt Valgrind das Melden von Fehlern nach insgesamt 10,000,000 oder 1,000
verschiedene, gesehen worden. Dies dient dazu, die Fehlerverfolgungsmaschinerie zu stoppen
in Programmen mit vielen Fehlern zu einem enormen Performance-Overhead.

--error-exitcode= [Ursprünglich: 0]
Gibt einen alternativen Exit-Code an, der zurückgegeben werden soll, wenn Valgrind Fehler in der
Lauf. Bei der Einstellung auf den Standardwert (Null) wird der Rückgabewert von Valgrind immer
der Rückgabewert des simulierten Prozesses sein. Wenn auf einen Wert ungleich Null gesetzt, wird das
Wert wird stattdessen zurückgegeben, wenn Valgrind Fehler erkennt. Dies ist nützlich für die Verwendung
Valgrind als Teil einer automatisierten Testsuite, da es die Erkennung von Tests erleichtert
Fälle, für die Valgrind Fehler gemeldet hat, einfach durch Überprüfung der Rückkehrcodes.

--error-markers= , [Ursprünglich: keiner]
Wenn Fehler als Klartext ausgegeben werden (dh XML nicht verwendet), --error-markers weist an
eine Zeile ausgeben, die das enthält beginnen (Ende) Zeichenfolge vor (nach) jedem Fehler.

Solche Markierungslinien erleichtern das Suchen nach Fehlern und/oder das Extrahieren von Fehlern in einem
Ausgabedatei, die mit der Programmausgabe gemischte Valgrind-Fehler enthält.

Beachten Sie, dass leere Marker akzeptiert werden. Es ist also nur die Verwendung eines Anfangs- (oder End-) Markers
möglich.

--sigill-diagnostics= [Ursprünglich: Jawohl]
Aktivieren/Deaktivieren des Druckens von Diagnosen für ungültige Befehle. Standardmäßig aktiviert, aber
standardmäßig deaktiviert, wenn --ruhig gegeben ist. Die Vorgabe kann immer explizit sein
durch Angabe dieser Option überschrieben.

Wenn diese Option aktiviert ist, wird eine Warnmeldung zusammen mit einigen Diagnosen gedruckt, wenn
Es wird eine Anweisung angetroffen, die Valgrind nicht dekodieren oder übersetzen kann, bevor die
Programm erhält ein SIGILL-Signal. Häufig weist eine illegale Anweisung auf einen Fehler in der
Programm oder fehlende Unterstützung für die jeweilige Anweisung in Valgrind. Aber einige
Programme versuchen absichtlich, eine Anweisung auszuführen, die möglicherweise fehlt und Trap
das SIGILL-Signal, um Prozessormerkmale zu erkennen. Die Verwendung dieses Flags ermöglicht es,
vermeiden Sie die Diagnoseausgabe, die Sie sonst in solchen Fällen erhalten würden.

--show-below-main= [Ursprünglich: Nein]
Standardmäßig zeigen Stacktraces für Fehler keine Funktionen an, die darunter erscheinen Haupt-
weil es meistens uninteressantes C-Library-Zeug und/oder Kauderwelsch ist.
Alternativ, wenn Haupt- nicht im Stacktrace vorhanden ist, werden Stacktraces nicht angezeigt
alle Funktionen unten Haupt--ähnliche Funktionen wie die von glibc __libc_start_main.
Wenn darüber hinaus Haupt--ähnliche Funktionen sind im Trace vorhanden, sie werden normalisiert als
(unten hauptsächlich), um die Ausgabe deterministischer zu machen.

Wenn diese Option aktiviert ist, werden alle Stacktrace-Einträge angezeigt und Haupt--Ähnlich
Funktionen werden nicht normalisiert.

--fullpath-after= [Ursprünglich: nicht erklären Quelle Pfade]
Standardmäßig zeigt Valgrind nur die Dateinamen in Stack-Traces an, aber keine vollständigen Pfade zu
Quelldaten. Wenn Sie Valgrind in großen Projekten verwenden, in denen sich die Quellen befinden in
mehrere verschiedene Verzeichnisse, kann dies umständlich sein. --fullpath-after stellt ein
flexible Lösung für dieses Problem. Wenn diese Option vorhanden ist, wird der Pfad zu jedem
Quelldatei wird angezeigt, mit der folgenden wichtigen Einschränkung: if Schnur ist zu finden in
der Weg, dann der Weg bis einschließlich Schnur wird weggelassen, sonst wird der Pfad angezeigt
unverändert. Beachten Sie, dass Schnur muss kein Präfix des Pfads sein.

Betrachten Sie beispielsweise eine Datei namens /home/janedoe/blah/src/foo/bar/xyzzy.c. Angabe
--fullpath-after=/home/janedoe/blah/src/ bewirkt, dass Valgrind den Namen als . anzeigt
foo/bar/xyzzy.c.

Da die Zeichenfolge kein Präfix sein muss, --fullpath-after=src/ wird herstellen
die gleiche Ausgabe. Dies ist nützlich, wenn der Pfad beliebige maschinengenerierte
Zeichen. Der Pfad /my/build/dir/C32A1B47/blah/src/foo/xyzzy kann beispielsweise lauten
auf foo/xyzzy gekürzt mit --fullpath-after=/blah/src/.

Wenn Sie nur den vollständigen Pfad sehen möchten, geben Sie einfach eine leere Zeichenfolge an:
--fullpath-after=. Dies ist kein Sonderfall, sondern lediglich eine logische Konsequenz der
oben genannten Regeln.

Schließlich können Sie verwenden --fullpath-after mehrmals. Jedes Auftreten davon verursacht
Valgrind, um zur Erzeugung vollständiger Pfade zu wechseln und die obige Filterregel anzuwenden. Jeder
erzeugter Pfad wird mit allen --fullpath-after-angegebene Zeichenfolgen, in der
Reihenfolge angegeben. Die erste übereinstimmende Zeichenfolge bewirkt, dass der Pfad abgeschnitten wird als
oben beschrieben. Wenn keine Übereinstimmung vorhanden ist, wird der vollständige Pfad angezeigt. Das erleichtert das Abhacken
Präfixe, wenn die Quellen aus einer Reihe von nicht verwandten Verzeichnissen stammen.

--extra-debuginfo-path= [Ursprünglich: undefiniert und ungebraucht]
Standardmäßig sucht Valgrind in mehreren bekannten Pfaden nach Debug-Objekten, wie z
/usr/lib/debug/.

Es kann jedoch Szenarien geben, in denen Sie Debug-Objekte an einen
beliebiger Speicherort, z. B. externer Speicher, wenn Valgrind auf einem mobilen Gerät ausgeführt wird
mit begrenztem lokalen Speicher. Ein weiteres Beispiel könnte eine Situation sein, in der Sie kein
Berechtigung zum Installieren von Debug-Objektpaketen auf dem System, auf dem Sie ausgeführt werden
Valgrind.

In diesen Szenarien können Sie einen absoluten Pfad als zusätzlichen, letzten Ort für angeben
Valgrind zum Suchen nach Debug-Objekten durch Angabe von
--extra-debuginfo-path=/path/to/debug/objects. Der angegebene Pfad wird dem vorangestellt
absoluter Pfadname des gesuchten Objekts. Zum Beispiel, wenn Valgrind sucht nach
die Debuginfo für /w/x/y/zz.so und --extra-debuginfo-path=/a/b/c angegeben ist, wird es
Suchen Sie unter /a/b/c/w/x/y/zz.so nach einem Debug-Objekt.

Dieses Flag sollte nur einmal angegeben werden. Bei mehrfacher Angabe werden nur die
letzte Instanz wird geehrt.

--debuginfo-server=ipaddr:port [Ursprünglich: undefiniert und ungebraucht]
Dies ist eine neue, experimentelle Funktion, die in Version 3.9.0 eingeführt wurde.

In einigen Szenarien kann es praktisch sein, Debuginfos von Objekten zu lesen, die auf einem
andere Maschine. Mit diesem Flag fragt Valgrind einen Debuginfo-Server ab, der auf läuft
ipaddr und lauschen auf Port-Port, wenn es das debuginfo-Objekt im lokalen nicht finden kann
Dateisystem.

Der Debuginfo-Server muss TCP-Verbindungen am Port-Port akzeptieren. Der Debuginfo-Server ist
in der Quelldatei auxprogs/valgrind-di-server.c enthalten. Es wird nur serviert von
das Verzeichnis, in dem es gestartet wird. port ist sowohl auf dem Client als auch auf dem Server standardmäßig auf 1500, wenn
keine Angabe.

Wenn Valgrind mithilfe des Debuginfo-Servers nach der Debuginfo für /w/x/y/zz.so sucht,
entfernt die Pfadnamenkomponenten und fordert lediglich zz.so auf dem Server an. Das in
turn sucht nur in seinem aktuellen Arbeitsverzeichnis nach einem passenden debuginfo-Objekt.

Die Debuginfo-Daten werden in kleinen Fragmenten (8 KB) wie von Valgrind angefordert übertragen.
Jeder Block wird mit LZO komprimiert, um die Übertragungszeit zu reduzieren. Die Umsetzung hat
auf beste Leistung über eine einstufige 802.11g (WiFi)-Netzwerkverbindung abgestimmt.

Beachten Sie, dass mithilfe von GNU Debuglink CRC überprüft wird, ob primäre und Debug-Objekte übereinstimmen
Schema, werden auch bei Verwendung des debuginfo-Servers ausgeführt. Um eine solche Überprüfung zu deaktivieren,
Sie müssen auch --allow-mismatched-debuginfo=yes angeben.

Standardmäßig erstellt das Valgrind-Build-System valgrind-di-server für das Ziel
Plattform, was mit ziemlicher Sicherheit nicht das ist, was Sie wollen. Bisher konnten wir nicht
Finden Sie heraus, wie Sie automake/autoconf dazu bringen, es für die Build-Plattform zu erstellen. Falls Sie es wollen
Um es zu verwenden, müssen Sie es von Hand mit dem oben angezeigten Befehl neu kompilieren
auxprogs/valgrind-di-server.c.

--allow-mismatched-debuginfo=no|yes [Nein]
Beim Lesen von Debuginfo aus separaten Debuginfo-Objekten überprüft Valgrind standardmäßig
dass die main- und debuginfo-Objekte übereinstimmen, indem der GNU-Debuglink-Mechanismus verwendet wird. Dies
garantiert, dass Debuginfo nicht aus veralteten Debuginfo-Objekten gelesen wird, und
sorgt auch dafür, dass Valgrind nicht aufgrund von Fehlanpassungen abstürzen kann.

Diese Prüfung kann mit --allow-mismatched-debuginfo=yes überschrieben werden. Das mag sein
nützlich, wenn die debuginfo- und main-Objekte nicht richtig aufgeteilt wurden. Sei
Seien Sie jedoch vorsichtig, wenn Sie dies verwenden: Es deaktiviert alle Konsistenzprüfungen und Valgrind
wurde beobachtet, dass es abstürzt, wenn die Objekte main und debuginfo nicht übereinstimmen.

--suppressions= [Ursprünglich: $PREFIX/lib/valgrind/default.supp]
Gibt eine zusätzliche Datei an, aus der Beschreibungen der zu unterdrückenden Fehler gelesen werden. Du darfst
Verwenden Sie bis zu 100 zusätzliche Unterdrückungsdateien.

--gen-suppressions= [Ursprünglich: Nein]
Wenn auf eingestellt ja, Valgrind pausiert nach jedem angezeigten Fehler und druckt die Zeile:

---- Druckunterdrückung ? --- [Zurück/N/n/J/j/C/c] ----

Drücken Rechtoder N Recht or n Recht, bewirkt, dass Valgrind die Ausführung fortsetzt, ohne zu drucken a
Unterdrückung für diesen Fehler.

Drücken Y Recht or y Recht bewirkt, dass Valgrind eine Unterdrückung für diesen Fehler schreibt. Du kannst
dann schneide es aus und füge es in eine Unterdrückungsdatei ein, wenn du nichts von dem hören möchtest
Fehler in der Zukunft.

Wenn auf eingestellt alle, druckt Valgrind für jeden gemeldeten Fehler eine Unterdrückung, ohne
den Benutzer abfragen.

Diese Option ist besonders bei C++-Programmen nützlich, da sie die
Unterdrückungen mit verstümmelten Namen, wie erforderlich.

Beachten Sie, dass die gedruckten Unterdrückungen so spezifisch wie möglich sind. Vielleicht möchten Sie gemeinsam
ähnliche durch Hinzufügen von Platzhaltern zu Funktionsnamen und durch die Verwendung von Frame-Ebene
Platzhalter. Die Wildcarding-Einrichtungen sind leistungsstark und dennoch flexibel und mit ein bisschen
Bei sorgfältiger Bearbeitung können Sie möglicherweise eine ganze Familie verwandter Fehler mit . unterdrücken
nur wenige Unterdrückungen.

Manchmal werden zwei verschiedene Fehler durch dieselbe Unterdrückung unterdrückt, in diesem Fall
Valgrind wird die Unterdrückung mehr als einmal ausgeben, aber Sie müssen nur eine haben
kopieren Sie in Ihre Unterdrückungsdatei (aber mehr als eine zu haben, wird keine Probleme verursachen). Ebenfalls,
der Unterdrückungsname lautet ; der Name nicht
wirklich egal, es wird nur mit dem verwendet -v Option, die alle verwendeten Unterdrückungen ausdruckt
Records.

--input-fd= [Ursprünglich: 0, stdin]
Beim Benutzen --gen-suppressions=ja, Valgrind stoppt, um Tastatureingaben zu lesen
von Ihnen, wenn jeder Fehler auftritt. Standardmäßig liest es von der Standardeingabe (stdin),
was bei Programmen problematisch ist, die stdin schließen. Mit dieser Option können Sie angeben
ein alternativer Dateideskriptor, von dem die Eingabe gelesen werden soll.

--dsymutil=nein|ja [Ja]
Diese Option ist nur relevant, wenn Valgrind unter Mac OS X ausgeführt wird.

Mac OS X verwendet ein Verknüpfungsschema für verzögerte Debug-Informationen (debuginfo). Wenn Objekt
Dateien, die Debuginfo enthalten, sind in eine .dylib oder eine ausführbare Datei eingebunden, die Debuginfo ist
nicht in die endgültige Datei kopiert. Stattdessen muss die Debuginfo manuell verlinkt werden durch
Ausführen von dsymutil, einem vom System bereitgestellten Dienstprogramm, auf der ausführbaren Datei oder .dylib. Die
resultierende kombinierte Debuginfo wird in einem Verzeichnis neben der ausführbaren Datei abgelegt oder
.dylib, jedoch mit der Erweiterung .dSYM.

Bei --dsymutil=nein, Valgrind erkennt Fälle, in denen das .dSYM-Verzeichnis entweder
fehlt oder vorhanden ist, aber nicht mit der zugehörigen ausführbaren Datei übereinstimmt oder
.dylib, wahrscheinlich weil es veraltet ist. In diesen Fällen druckt Valgrind ein
Warnmeldung, aber führen Sie keine weiteren Maßnahmen durch.

Bei --dsymutil=ja, führt Valgrind in solchen Fällen dsymutil automatisch als
notwendig, um die Debuginfo auf den neuesten Stand zu bringen. Für alle praktischen Zwecke, wenn Sie immer
- --dsymutil=ja, dann müssen Sie dsymutil nie manuell oder als Teil ausführen
des Build-Systems Ihrer Anwendungen, da Valgrind es bei Bedarf ausführt.

Valgrind wird nicht versuchen, dsymutil auf einer ausführbaren Datei oder Bibliothek in auszuführen / usr /,
/ Behälter /, / sbin /, / Opt /, /sw/, /System/, /Library/ oder /Applications/ da dsymutil
scheitern immer in solchen Situationen. Es schlägt beides fehl, weil die Debuginfo für solche
vorinstallierte Systemkomponenten nirgends verfügbar ist, und auch weil es so wäre
benötigen Schreibrechte in diesen Verzeichnissen.

Seien Sie vorsichtig bei der Verwendung --dsymutil=ja, da es bereits vorhandene .dSYM
Verzeichnisse, die stillschweigend gelöscht und neu erstellt werden. Beachten Sie auch, dass dsymutil ziemlich ist
langsam, manchmal übertrieben.

--max-stackframe= [Ursprünglich: 2000000]
Die maximale Größe eines Stapelrahmens. Wenn sich der Stapelzeiger um mehr als diesen Betrag bewegt
dann geht Valgrind davon aus, dass das Programm auf einen anderen Stack wechselt.

Sie müssen diese Option möglicherweise verwenden, wenn Ihr Programm über große Stapel-zugeordnete Arrays verfügt.
Valgrind verfolgt den Stack-Zeiger Ihres Programms. Wenn es sich um mehr als die ändert
Schwellenwert, geht Valgrind davon aus, dass Ihr Programm zu einem anderen Stack wechselt, und
Memcheck verhält sich anders als bei einer Stack-Pointer-Änderung, die kleiner als der ist
Schwelle. Normalerweise funktioniert diese Heuristik gut. Wenn Ihr Programm jedoch große
Strukturen auf dem Stack wird diese Heuristik getäuscht, und Memcheck wird anschließend
melden eine große Anzahl von ungültigen Stack-Zugriffen. Mit dieser Option können Sie die
Schwelle auf einen anderen Wert.

Sie sollten diese Option nur in Betracht ziehen, wenn die Debug-Ausgabe von Valgrind Sie dazu anweist
tun Sie dies. In diesem Fall wird Ihnen der neue Schwellenwert mitgeteilt, den Sie angeben sollten.

Im Allgemeinen ist es eine schlechte Idee, große Strukturen auf dem Stack zuzuweisen, da Sie
geht leicht der Stack-Speicherplatz aus, insbesondere auf Systemen mit begrenztem Speicher oder denen
erwarten, eine große Anzahl von Threads mit jeweils einem kleinen Stack zu unterstützen, und auch weil
die von Memcheck durchgeführte Fehlerprüfung ist für heap-allozierte Daten effektiver
als für Stack-zugeordnete Daten. Wenn Sie diese Option verwenden müssen, möchten Sie vielleicht
Ziehen Sie in Betracht, Ihren Code neu zu schreiben, um ihn auf dem Heap statt auf dem Stack zuzuweisen.

--main-stacksize= [Ursprünglich: - Strom 'unbegrenzt' Wert]
Gibt die Größe des Stapels des Haupt-Threads an.

Um die Speicherverwaltung zu vereinfachen, reserviert Valgrind den gesamten erforderlichen Speicherplatz für das Haupt
Thread-Stack beim Start. Das bedeutet, dass es die erforderliche Stack-Größe bei . kennen muss
Anfang.

Standardmäßig verwendet Valgrind den aktuellen "ulimit"-Wert für die Stack-Größe oder 16 MB.
was auch immer niedriger ist. In vielen Fällen ergibt dies eine Stackgröße im Bereich von 8 bis 16 MB,
die für die meisten Anwendungen fast nie überläuft.

Wenn Sie eine größere Gesamtstapelgröße benötigen, verwenden Sie --main-stacksize es anzugeben. Nur einstellen
so hoch, wie Sie benötigen, da weit mehr Platz reserviert wird, als Sie benötigen (d. h. Hunderte
Megabyte mehr als Sie benötigen) schränkt die Speicherzuordnungen von Valgrind ein und kann
Reduzieren Sie den Gesamtspeicher, den Valgrind verwenden kann. Das ist nur wirklich von
Bedeutung auf 32-Bit-Rechnern.

Unter Linux können Sie einen Stapel mit einer Größe von bis zu 2 GB anfordern. Valgrind hört mit a . auf
Diagnosemeldung, wenn der Stack nicht belegt werden kann.

--main-stacksize wirkt sich nur auf die Stapelgröße für den anfänglichen Thread des Programms aus. Es hat
keinen Einfluss auf die Größe der Thread-Stacks, da Valgrind diese nicht zuweist.

Möglicherweise müssen Sie beide verwenden --main-stacksize und --max-stackframe zusammen. es ist
wichtig das zu verstehen --main-stacksize legt die maximale Gesamtstapelgröße fest,
indem --max-stackframe gibt die größte Größe eines Stapelrahmens an. Du wirst
muss das erarbeiten --main-stacksize Wert für dich selbst (normalerweise, wenn du
Anwendungssegfaults). Aber Valgrind wird dir das Notwendige sagen --max-stackframe Größe,
Falls benötigt.

Wie weiter in der Beschreibung von . besprochen --max-stackframe, eine Voraussetzung für eine große
Stack ist ein Zeichen für potenzielle Portabilitätsprobleme. Am besten platzieren Sie alle
große Datenmengen im Heap-zugeordneten Speicher.

--max-threads= [Ursprünglich: 500]
Standardmäßig kann Valgrind bis zu 500 Threads verarbeiten. Gelegentlich ist diese Zahl auch
klein. Verwenden Sie diese Option, um einen anderen Grenzwert anzugeben. ZB --max-threads=3000.

MALLOC()-VERWANDTE OPTIONAL

Für Tools, die eine eigene Version von malloc verwenden (z. B. Memcheck, Massif, Helgrind, DRD),
folgende Optionen gelten.

--Ausrichtung= [Ursprünglich: 8 or 16, abhängig on Plattform]
Standardmäßig ist Valgrinds malloc, Realloc, usw., gibt einen Block zurück, dessen Startadresse ist
8-Byte-ausgerichtet oder 16-Byte-ausgerichtet (der Wert hängt von der Plattform ab und entspricht dem
Plattformstandard). Mit dieser Option können Sie eine andere Ausrichtung angeben. Die
Der angegebene Wert muss größer oder gleich dem Standard sein, kleiner oder gleich
4096 und muss eine Zweierpotenz sein.

--redzone-size= [Ursprünglich: hängt on Werkzeug]
Valgrinds Malloc, realloc, usw., fügen Sie Füllblöcke vor und nach jedem Heap-Block hinzu
durch das ausgeführte Programm zugewiesen. Solche Füllblöcke werden Redzones genannt. Die
Der Standardwert für die Redzone-Größe hängt vom Werkzeug ab. Zum Beispiel fügt Memcheck hinzu und
schützt mindestens 16 Byte vor und nach jedem vom Client zugewiesenen Block.
Damit kann er Blockunterläufe oder Überläufe von bis zu 16 Byte erkennen.

Durch Erhöhen der Redzone-Größe können Überschreitungen größerer Distanzen erkannt werden,
erhöht jedoch den von Valgrind verwendeten Speicher. Das Verringern der Redzone-Größe wird
reduziert den von Valgrind benötigten Speicher, verringert aber auch die Erkennungswahrscheinlichkeit
Über-/Unterschreitung, wird also nicht empfohlen.

UNGEWÖHNLICH OPTIONAL

Diese Optionen gelten für alle Werkzeuge, da sie bestimmte obskure Funktionen des Valgrind . betreffen
Ader. Die meisten Leute werden sie nicht brauchen.

--smc-check= [Ursprünglich: alles-nicht-Datei für x86/amd64/s390x,
Stapel für Andere Bögen]
Diese Option steuert die Erkennung von selbstmodifizierendem Code durch Valgrind. Wenn keine Überprüfung ist
done, wenn ein Programm Code ausführt, dann mit neuem Code überschreibt, und
den neuen Code ausführt, führt Valgrind weiterhin die Übersetzungen aus, für die es erstellt wurde
der alte Code. Dies führt wahrscheinlich zu falschem Verhalten und/oder Abstürzen.

Für "moderne" Architekturen - alles, was nicht x86, amd64 oder s390x ist - die Standardeinstellung
is Stapel. Dies liegt daran, dass ein korrektes Programm explizite Maßnahmen zur Wiederherstellung ergreifen muss
DI-Cache-Kohärenz nach Codeänderung. Valgrind beobachtet und ehrt solche
Aktionen, mit dem Ergebnis, dass selbstmodifizierender Code transparent mit Null behandelt wird
Extrakosten.

Für x86, amd64 und s390x muss das Programm die Hardware nicht benachrichtigen
erforderliche DI-Kohärenzsynchronisierung. Daher ist die Standardeinstellung alles-nicht-Datei, die die
Normalfall der Generierung von Code in einen anonymen (nicht dateigestützten) mmap'd-Bereich.

Die Bedeutungen der vier verfügbaren Einstellungen sind wie folgt. Kein Nachweis (keine),
erkennen selbstmodifizierenden Code auf dem Stack (der von GCC verwendet wird, um verschachtelte
Funktionen) (Stapel), überall selbstmodifizierenden Code erkennen (alle) und erkennen
selbstmodifizierender Code überall außer in dateigestützten Mappings (alles-nicht-Datei).

Laufen mit alle wird Valgrind merklich verlangsamen. Laufen mit keine wird selten
beschleunigen, da in den meisten Programmen nur sehr wenig Code dynamisch generiert wird.
Der VALGRIND_DISCARD_TRANSLATIONS Kundenanfrage ist eine Alternative zu --smc-check=alle
und --smc-check=alle-keine-Datei das erfordert mehr Programmieraufwand, ermöglicht aber Valgrind
um Ihr Programm schneller auszuführen, indem Sie ihm genau sagen, wann Übersetzungen angefertigt werden müssen
neu gemacht.

--smc-check=alle-keine-Datei bietet eine günstigere, aber eingeschränktere Version von
--smc-check=alle. Es fügt Überprüfungen zu allen Übersetzungen hinzu, die nicht von . stammen
dateigestützte Speicherzuordnungen. Typische Anwendungen, die Code generieren, zum Beispiel JITs
Generieren Sie in Webbrowsern Code in anonyme Mmaped-Bereiche, während der "feste" Code
des Browsers lebt immer in dateigestützten Zuordnungen. --smc-check=alle-keine-Datei nimmt
Vorteil dieser Beobachtung ist, den Overhead der Überprüfung auf Code zu begrenzen, der
wahrscheinlich JIT generiert werden.

--read-inline-info= [Ursprünglich: sehen unten]
Wenn aktiviert, liest Valgrind Informationen zu eingebetteten Funktionsaufrufen von DWARF3
Debug-Informationen. Dies verlangsamt den Start von Valgrind und verwendet mehr Speicher (normalerweise für
jedes Inline-Stück Code, 6 Wörter und Leerzeichen für den Funktionsnamen), aber es ergibt sich
in beschreibenderen Stacktraces. Für die Version 3.10.0 ist diese Funktionalität aktiviert
standardmäßig nur für Linux-, Android- und Solaris-Ziele und nur für die Tools
Memcheck, Helgrind und DRD. Hier ist ein Beispiel für einige Stacktraces mit
--read-inline-info=nein:

==15380== Bedingter Sprung oder Bewegung hängt von nicht initialisierten Wert(en) ab
==15380== bei 0x80484EA: main (inlinfo.c:6)
==15380==
==15380== Bedingter Sprung oder Bewegung hängt von nicht initialisierten Wert(en) ab
==15380== bei 0x8048550: fun_noninline (inlinfo.c:6)
==15380== von 0x804850E: main (inlinfo.c:34)
==15380==
==15380== Bedingter Sprung oder Bewegung hängt von nicht initialisierten Wert(en) ab
==15380== bei 0x8048520: main (inlinfo.c:6)

Und hier sind die gleichen Fehler mit --read-inline-info=ja:

==15377== Bedingter Sprung oder Bewegung hängt von nicht initialisierten Wert(en) ab
==15377== bei 0x80484EA: fun_d (inlinfo.c:6)
==15377== von 0x80484EA: fun_c (inlinfo.c:14)
==15377== von 0x80484EA: fun_b (inlinfo.c:20)
==15377== von 0x80484EA: fun_a (inlinfo.c:26)
==15377== von 0x80484EA: main (inlinfo.c:33)
==15377==
==15377== Bedingter Sprung oder Bewegung hängt von nicht initialisierten Wert(en) ab
==15377== bei 0x8048550: fun_d (inlinfo.c:6)
==15377== von 0x8048550: fun_noninline (inlinfo.c:41)
==15377== von 0x804850E: main (inlinfo.c:34)
==15377==
==15377== Bedingter Sprung oder Bewegung hängt von nicht initialisierten Wert(en) ab
==15377== bei 0x8048520: fun_d (inlinfo.c:6)
==15377== von 0x8048520: main (inlinfo.c:35)

--read-var-info= [Ursprünglich: Nein]
Wenn aktiviert, liest Valgrind Informationen über Variablentypen und -orte von
DWARF3-Debug-Informationen. Dies verlangsamt den Start von Valgrind erheblich und macht es nutzbar
deutlich mehr Speicher, aber für die Tools, die ihn nutzen können (Memcheck,
Helgrind, DRD) kann es zu genaueren Fehlermeldungen kommen. Hier sind zum Beispiel
einige von Memcheck ausgegebene Standardfehler:

==15363== Nicht initialisierte(s) Byte(s) während der Client-Prüfanforderung gefunden
==15363== bei 0x80484A9: Krächzen (varinfo1.c:28)
==15363== von 0x8048544: Haupt (varinfo1.c:55)
==15363== Adresse 0x80497f7 ist 7 Byte im Datensymbol "global_i2"
==15363==
==15363== Nicht initialisierte(s) Byte(s) während der Client-Prüfanforderung gefunden
==15363== bei 0x80484A9: Krächzen (varinfo1.c:28)
==15363== von 0x8048550: Haupt (varinfo1.c:56)
==15363== Adresse 0xbea0d0cc ist auf dem Stack von Thread 1
==15363== in Frame #1, erstellt von main (varinfo1.c:45)

Und hier sind die gleichen Fehler mit --read-var-info=ja:

==15370== Nicht initialisierte(s) Byte(s) während der Client-Prüfanforderung gefunden
==15370== bei 0x80484A9: Krächzen (varinfo1.c:28)
==15370== von 0x8048544: Haupt (varinfo1.c:55)
==15370== Ort 0x80497f7 ist 0 Byte in global_i2[7],
==15370== eine globale Variable deklariert unter varinfo1.c:41
==15370==
==15370== Nicht initialisierte(s) Byte(s) während der Client-Prüfanforderung gefunden
==15370== bei 0x80484A9: Krächzen (varinfo1.c:28)
==15370== von 0x8048550: Haupt (varinfo1.c:56)
==15370== Ort 0xbeb4a0cc ist 0 Bytes innerhalb der lokalen Variablen "local"
==15370== deklariert bei varinfo1.c:46, in Frame #1 von Thread 1

--vgdb-poll= [Ursprünglich: 5000]
Als Teil seiner Hauptschleife wird der Valgrind-Scheduler eine Abfrage durchführen, um zu überprüfen, ob einige Aktivitäten
(wie ein externer Befehl oder eine Eingabe von einer gdb) muss von gdbserver verarbeitet werden.
Diese Aktivitätsumfrage wird durchgeführt, nachdem die angegebene Anzahl von Basisblöcken (oder
etwas mehr als die angegebene Anzahl von Basisblöcken). Diese Umfrage ist ziemlich billig, also die
Standardwert ist relativ niedrig eingestellt. Sie können diesen Wert weiter verringern, wenn vgdb
kann den ptrace-Systemaufruf nicht verwenden, um Valgrind zu unterbrechen, wenn alle Threads
Uhrzeit) in einem Systemaufruf blockiert.

--vgdb-shadow-registers=nein|ja [Ursprünglich: Nein]
Wenn aktiviert, stellt gdbserver die Valgrind-Schattenregister für GDB bereit. Mit diesem,
der Wert der Valgrind-Schattenregister kann mit GDB überprüft oder geändert werden.
Das Freigeben von Schattenregistern funktioniert nur mit GDB-Version 7.1 oder höher.

--vgdb-prefix= [Ursprünglich: /tmp/vgdb-pipe]
Um mit gdb/vgdb zu kommunizieren, erstellt der Valgrind gdbserver 3 Dateien (2 benannte FIFOs
und eine MMAP-Datei mit gemeinsam genutztem Speicher). Die Präfix-Option steuert das Verzeichnis und das Präfix
für die Erstellung dieser Dateien.

--run-libc-freeres= [Ursprünglich: Jawohl]
Diese Option ist nur relevant, wenn Valgrind unter Linux ausgeführt wird.

Die GNU-C-Bibliothek (libc.so), die von allen Programmen verwendet wird, kann Speicher für
seine eigenen Verwendungen. Normalerweise stört es nicht, diesen Speicher freizugeben, wenn das Programm endet –
Es hätte keinen Sinn, da der Linux-Kernel alle Prozessressourcen zurückfordert, wenn a
Prozess wird sowieso beendet, also würde es die Dinge nur verlangsamen.

Die glibc-Autoren haben erkannt, dass dieses Verhalten Leckprüfer wie Valgrind,
um fälschlicherweise Lecks in der glibc zu melden, wenn beim Beenden eine Leckprüfung durchgeführt wird. Um zu vermeiden
Dazu stellten sie eine Routine namens . bereit __libc_freeres speziell um glibc freizugeben
der gesamte Speicher, den es zugewiesen hat. Memcheck versucht daher zu laufen __libc_freeres am Ausgang.

Leider ist in einigen sehr alten Versionen von glibc, __libc_freeres ist ausreichend
fehlerhaft, um Segmentierungsfehler zu verursachen. Besonders auffällig war dies bei Red Hat 7.1.
Diese Option wird also bereitgestellt, um den Ablauf von zu verhindern __libc_freeres. Wenn Ihr
Programm scheint auf Valgrind gut zu laufen, aber Segfaults beim Beenden, das können Sie feststellen
--run-libc-freeres=nein behebt das, allerdings auf Kosten einer möglicherweise falschen Berichterstattung
Platzlecks in libc.so.

--sim-hints=Hinweis1,Hinweis2,...
Übergeben Sie verschiedene Hinweise an Valgrind, die das simulierte Verhalten in
nicht standardmäßige oder gefährliche Methoden, möglicherweise um die Simulation seltsamer Merkmale zu unterstützen. Von
Standardmäßig sind keine Hinweise aktiviert. Mit Vorsicht verwenden! Derzeit bekannte Hinweise sind:

· lax-ioctls: Seien Sie beim Umgang mit ioctl sehr locker; die einzige Annahme ist, dass die Größe
ist richtig. Erfordert nicht, dass der volle Puffer beim Schreiben initialisiert wird.
Ohne dies verwenden Sie einige Gerätetreiber mit einer großen Anzahl seltsamer ioctl
Befehle werden sehr ermüdend.

· sicherungskompatibel: Sonderbehandlung für bestimmte Systemaufrufe aktivieren, die möglicherweise blockieren
in einem FUSE-Dateisystem. Dies kann erforderlich sein, wenn Valgrind auf einem
Multithread-Programm, das einen Thread verwendet, um ein FUSE-Dateisystem zu verwalten und
einen anderen Thread, um auf dieses Dateisystem zuzugreifen.

· aktivieren-außen: Aktivieren Sie einige spezielle Magie, die erforderlich ist, wenn das ausgeführte Programm
selbst Valgrind.

· kein-inneres-präfix: Drucken eines Präfix deaktivieren > vor jedem stdout oder stderr
Ausgangsleitung in einem inneren Valgrind, die von einem äußeren Valgrind geführt wird. Das ist nützlich
beim Ausführen von Valgrind-Regressionstests in einem äußeren/inneren Setup. Notiere dass der
Präfix > wird immer vor den inneren Debug-Logging-Zeilen gedruckt.

· no-nptl-pthread-stackcache: Dieser Hinweis ist nur relevant, wenn Valgrind auf . läuft
Linux.

Die GNU glibc pthread-Bibliothek (libpthread.so), die von pthread-Programmen verwendet wird,
verwaltet einen Cache von Pthread-Stacks. Wenn ein Pthread beendet wird, wird der Speicher verwendet
für den Pthread-Stack und einige Datenstrukturen, die sich auf den lokalen Speicher des Threads beziehen, sind dies nicht
immer direkt freigegeben. Dieser Speicher wird in einem Cache gehalten (bis zu einer bestimmten Größe),
und wird wiederverwendet, wenn ein neuer Thread gestartet wird.

Dieser Cache bewirkt, dass das Helgrind-Tool eine falsch positive Racebedingung meldet
Fehler in diesem zwischengespeicherten Speicher, da helgrind die interne glibc nicht versteht
Cache-Synchronisationsprimitiven. Also, wenn du helgrind verwendest, deaktiviere den Cache
hilft, falsch positive Race-Bedingungen zu vermeiden, insbesondere bei der Verwendung von Thread
lokale Speichervariablen (zB Variablen, die die __Gewinde Qualifikation).

Bei Verwendung des memcheck-Tools stellt das Deaktivieren des Cache sicher, dass der Speicher von glibc verwendet wird
zur Behandlung von __thread-Variablen wird direkt freigegeben, wenn ein Thread beendet wird.

Hinweis: Valgrind deaktiviert den Cache mit Hilfe einiger interner Kenntnisse des glibc-Stacks
Cache-Implementierung und Prüfung der Debug-Informationen des pthread
Bücherei. Diese Technik ist daher etwas fragil und funktioniert möglicherweise nicht für alle glibc
Versionen. Dies wurde erfolgreich mit verschiedenen glibc-Versionen getestet (zB
2.11, 2.16, 2.18) auf verschiedenen Plattformen.

· Lax-Türen: (Nur Solaris) Seien Sie bei der Behandlung von Türsystemrufen sehr locker
nicht erkannte Türdateideskriptoren. Erfordert nicht, dass der volle Puffer ist
beim Schreiben initialisiert. Ohne dies können Programme mit libdoor(3LIB)-Funktionalität
mit vollständig proprietärer Semantik kann eine große Anzahl falsch positiver Ergebnisse melden.

--fair-sched= [Ursprünglich: Nein]
Der --fair-plan Option steuert den Sperrmechanismus, der von Valgrind zum Serialisieren verwendet wird
Thread-Ausführung. Der Sperrmechanismus steuert die Art und Weise, wie die Threads geplant werden,
und unterschiedliche Einstellungen ergeben unterschiedliche Kompromisse zwischen Fairness und Leistung. Zum
Weitere Details zum Valgrind-Thread-Serialisierungsschema und seinen Auswirkungen auf
Performance- und Thread-Scheduling finden Sie unter Scheduling und Multi-Thread-Leistung.

· Der Wert --fair-sched=ja aktiviert einen fairen Scheduler. Kurz gesagt, wenn mehrere
Threads zur Ausführung bereit sind, werden die Threads im Round-Robin-Verfahren geplant.
Dieser Mechanismus ist nicht auf allen Plattformen oder Linux-Versionen verfügbar. Wenn nicht
verfügbar, mit --fair-sched=ja führt dazu, dass Valgrind mit einem Fehler beendet wird.

Sie werden möglicherweise feststellen, dass diese Einstellung die allgemeine Reaktionsfähigkeit verbessert, wenn Sie ein
interaktives Multithread-Programm, zum Beispiel ein Webbrowser, auf Valgrind.

· Der Wert --fair-sched=versuchen aktiviert die Messeterminierung, sofern auf der Plattform verfügbar.
Andernfalls fällt es automatisch zurück auf --fair-sched=nein.

· Der Wert --fair-sched=nein aktiviert einen Scheduler, der keine Fairness garantiert
zwischen Threads bereit zur Ausführung, was aber im Allgemeinen die höchste Leistung bietet.

--kernel-variant=Variante1,Variante2,...
Behandeln von Systemaufrufen und ioctls, die sich aus kleineren Varianten des Standardkernels ergeben für
diese Plattform. Dies ist nützlich für die Ausführung auf gehackten Kerneln oder mit Kernelmodulen
die beispielsweise nicht standardmäßige ioctls unterstützen. Mit Vorsicht verwenden. Wenn nicht
Wenn Sie verstehen, was diese Option bewirkt, brauchen Sie sie mit ziemlicher Sicherheit nicht. Zur Zeit
bekannte Varianten sind:

· bproz: unterstütz die sys_broc Systemaufruf auf x86. Dies ist für die Ausführung auf BProc,
Dies ist eine kleinere Variante von Standard-Linux, die manchmal zum Erstellen verwendet wird
Cluster.

· android-no-HW-tls: Einige Versionen des Android-Emulators für ARM bieten kein a
Hardware-TLS (thread-local state) registrieren, und Valgrind stürzt beim Start ab. Verwenden
diese Variante, um die Softwareunterstützung für TLS auszuwählen.

· android-gpu-sgx5xx: Verwenden Sie dies, um die Handhabung von proprietären ioctls für die
GPUs der PowerVR SGX 5XX-Serie auf Android-Geräten. Wenn Sie dies nicht auswählen, ist dies nicht der Fall
Stabilitätsprobleme verursachen, kann aber dazu führen, dass Memcheck nach dem
Programm führt GPU-spezifische ioctls aus.

· android-gpu-adreno3xx: Verwenden Sie dies auf ähnliche Weise, um den Umgang mit proprietären . zu unterstützen
ioctls für die Qualcomm Adreno 3XX GPU-Serie auf Android-Geräten.

--merge-recursive-frames= [Ursprünglich: 0]
Einige rekursive Algorithmen, zum Beispiel balancierte Binärbaumimplementierungen, erzeugen
viele verschiedene Stack-Traces, die jeweils Aufrufzyklen enthalten. Ein Zyklus ist definiert als
zwei identische Programmzählerwerte getrennt durch Null oder mehr anderer Programmzähler
Werte. Valgrind benötigt dann möglicherweise viel Speicher, um all diese Stack-Traces zu speichern. Das ist
eine schlechte Speicherausnutzung, wenn man bedenkt, dass solche Stack-Traces wiederholt uninteressante
rekursive Aufrufe anstelle von interessanteren Informationen wie der Funktion, die hat
leitete den rekursiven Aufruf ein.

Die Option --merge-recursive-frames= weist Valgrind an, zu erkennen und zusammenzuführen
rekursive Aufrufzyklen mit einer Größe von bis zu Rahmen. Wenn ein solcher Zyklus ist
erkannt, zeichnet Valgrind den Zyklus im Stack-Trace als eindeutigen Programmzähler auf.

Der Wert 0 (Standard) bewirkt keine rekursive Anrufzusammenführung. Ein Wert von 1 verursacht
Stapelspuren einfacher rekursiver Algorithmen (zum Beispiel eine faktorielle Implementierung)
zusammengebrochen werden. Ein Wert von 2 wird normalerweise benötigt, um erzeugte Stack-Traces zu reduzieren
durch rekursive Algorithmen wie binäre Bäume, schnelle Sortierung usw. Höhere Werte können sein
für komplexere rekursive Algorithmen benötigt.

Hinweis: Rekursive Aufrufe werden durch Analyse der Programmzählerwerte erkannt. Sie sind nicht
erkannt, indem man sich die Funktionsnamen ansieht.

--num-transtab-sectors= [Ursprünglich: 6 für Android Plattformen, 16 für alle Andere]
Valgrind übersetzt und instrumentiert den Maschinencode Ihres Programms in kleine Fragmente
(Grundbausteine). Die Übersetzungen werden in einem Übersetzungscache gespeichert, der unterteilt ist
in eine Reihe von Abschnitten (Sektoren). Wenn der Cache voll ist, wird der Sektor mit den
ältesten Übersetzungen werden geleert und wiederverwendet. Wenn diese alten Übersetzungen wieder benötigt werden,
Valgrind muss den entsprechenden Maschinencode neu übersetzen und instrumentieren
teuer. Wenn der Arbeitssatz "ausgeführte Anweisungen" eines Programms groß ist, steigt
die Anzahl der Sektoren kann die Leistung verbessern, indem die Anzahl der
Rückübersetzungen nötig. Sektoren werden nach Bedarf zugeteilt. Einmal zugewiesen, kann ein Sektor
nie freigegeben werden und nimmt je nach Werkzeug und Wert viel Platz ein
of --avg-transstab-entry-size (ca. 40 MB pro Sektor für Memcheck). Nutze die Option
--stats=ja um genaue Informationen über den von einem Sektor belegten Speicher und die
Verteilung und Wiederverwendung von Sektoren.

--avg-transtab-entry-size= [Ursprünglich: 0, Bedeutung - Werkzeug vorausgesetzt Ursprünglich]
Durchschnittliche Größe des übersetzten Basisblocks. Diese durchschnittliche Größe wird verwendet, um die
Größe einer Branche. Jedes Werkzeug stellt einen zu verwendenden Standardwert bereit. Wenn dieser Standardwert
zu klein ist, werden die Übersetzungssektoren zu schnell voll. Wenn diese Standardeinstellung
Wenn der Wert zu groß ist, wird ein erheblicher Teil des Übersetzungssektorspeichers nicht verwendet.
Beachten Sie, dass die durchschnittliche Größe einer grundlegenden Blockübersetzung vom Werkzeug abhängt und möglicherweise
hängen von den Werkzeugoptionen ab. Zum Beispiel die memcheck-Option --track-origins=ja steigt
die Größe der grundlegenden Blockübersetzungen. Verwenden --avg-transstab-entry-size um die zu stimmen
Größe der Sektoren, entweder um Speicher zu gewinnen oder zu viele Rückübersetzungen zu vermeiden.

--aspace-minaddr= [Ursprünglich: hängt on Plattform]
Um potenzielle Konflikte mit einigen Systembibliotheken zu vermeiden, verwendet Valgrind die
Adressraum unten --aspace-minaddr Wert, reserviert für den Fall einer Bibliothek
fordert speziell Speicher in dieser Region an. Es wird also ein "pessimistischer" Wert vermutet
von Valgrind je nach Plattform. Unter Linux vermeidet Valgrind standardmäßig die Verwendung der
ersten 64 MB, auch wenn in dieser vollständigen Zone normalerweise kein Konflikt vorliegt. Sie können verwenden
die Option --aspace-minaddr damit Ihre speicherhungrige Anwendung davon profitiert
mehr von diesem geringeren Speicher. Auf der anderen Seite, wenn Sie auf einen Konflikt stoßen, erhöht sich
aspace-minaddr Wert könnte es lösen. Konflikte manifestieren sich typischerweise mit
mmap-Fehler im unteren Bereich des Adressraums. Die angegebene Adresse muss page . sein
ausgerichtet und muss gleich oder größer 0x1000 (4KB) sein. So finden Sie den Standardwert auf Ihrem
Plattform, tun Sie etwas wie valgrind -d -d date 2>&1 | grep -i minddr. Werte
kleiner als 0x10000 (64KB) sind dafür bekannt, dass sie bei einigen Distributionen Probleme verursachen.

--valgrind-stacksize= [Ursprünglich: 1 MB]
Für jeden Thread benötigt Valgrind seinen eigenen 'privaten' Stack. Die Standardgröße für diese
Stapel ist groß dimensioniert und sollte daher in den meisten Fällen ausreichen. Falls die
Wenn die Größe zu klein ist, wird Valgrind einen Fehler melden. Vor dem Segfaulting könnte eine Warnung lauten
von Valgrind erzeugt, wenn er sich dem Limit nähert.

Nutze die Option --valgrind-stacksize wenn eine solche (unwahrscheinliche) Warnung ausgegeben wird, oder
Valgrind stirbt aufgrund einer Segmentierungsverletzung. Solche Segmentierungsverletzungen wurden
beim Entschlüsseln riesiger C++-Symbole gesehen.

Wenn Ihre Anwendung viele Threads verwendet und viel Speicher benötigt, können Sie einige gewinnen
Speicher durch Reduzieren der Größe dieser Valgrind-Stacks mit der Option
--valgrind-stacksize.

--show-emwarns= [Ursprünglich: Nein]
Wenn aktiviert, gibt Valgrind in bestimmten Fällen Warnungen über seine CPU-Emulation aus.
Diese sind normalerweise nicht interessant.

--require-text-symbol=:sonnamepatt:fnnamepatt
Wenn ein gemeinsam genutztes Objekt, dessen Soname übereinstimmt sonamepatt wird in den Prozess geladen,
Untersuchen Sie alle exportierten Textsymbole. Wenn keiner davon passt fnnamepatt, drucken und
Fehlermeldung und brechen Sie den Lauf ab. Dadurch kann sichergestellt werden, dass der Lauf
nicht fortfahren, es sei denn, ein bestimmtes gemeinsam genutztes Objekt enthält einen bestimmten Funktionsnamen.

Beide sonamepatt und fnnamepatt kann mit den üblichen geschrieben werden ? und * Platzhalter. Zum
Beispiel: ":*libc.so*:foo?bar". Sie können zum Trennen auch andere Zeichen als einen Doppelpunkt verwenden
die beiden Muster. Wichtig ist nur, dass das erste Zeichen und das Trennzeichen
Charakter sind gleich. Zum Beispiel könnte das obige Beispiel auch geschrieben werden
"Q*libc.so*Qfoo?bar". Mehrere
--text-symbol erforderlich Flags sind erlaubt, in diesem Fall werden gemeinsam genutzte Objekte geladen
in den Prozess wird gegen alle geprüft.

Dies dient dazu, die zuverlässige Verwendung von Markup-Bibliotheken zu unterstützen. Zum Beispiel,
Angenommen, wir haben eine Version von GCCs libgomp.so die mit markiert wurde
Anmerkungen zur Unterstützung von Helgrind. Es ist nur zu einfach und verwirrend, die falschen,
nicht kommentiert libgomp.so in die Bewerbung ein. Die Idee ist also: Fügen Sie ein Textsymbol in die
Markup-Bibliothek, zum Beispiel annotated_for_helgrind_3_6, und dann gib die Flagge
--require-text-symbol=:*libgomp*so*:annotated_for_helgrind_3_6 so dass wenn libgomp.so
geladen ist, scannt Valgrind seine Symboltabelle, und wenn das Symbol nicht vorhanden ist, ist der Lauf
abgebrochen, anstatt stillschweigend mit der nicht markierten Bibliothek fortzufahren. Beachten Sie, dass Sie
sollte die gesamte Flagge in Anführungszeichen setzen, um zu verhindern, dass sich die Granaten nach oben ausdehnen * und ?
Platzhalter.

--soname-synonyms=syn1=Muster1,syn2=Muster2,...
Wenn eine gemeinsam genutzte Bibliothek geladen wird, sucht Valgrind nach Funktionen in der Bibliothek, die
müssen ersetzt oder verpackt werden. Memcheck ersetzt beispielsweise alle malloc-bezogenen
Funktionen (malloc, free, calloc, ...) mit eigenen Versionen. Solche Ersetzungen sind
wird standardmäßig nur in gemeinsam genutzten Bibliotheken durchgeführt, deren Soname mit einem vordefinierten Soname übereinstimmt
Muster (zB libc.so* unter Linux). Standardmäßig erfolgt kein Ersatz für eine statisch
verlinkte Bibliothek oder für alternative Bibliotheken wie tcmalloc. In einigen Fällen ist die
Ersatz erlauben --soname-synonyme um ein zusätzliches Synonymmuster anzugeben,
Flexibilität beim Austausch.

Derzeit ist diese Flexibilität nur für die malloc-bezogenen Funktionen zulässig, wobei
das synonym somalloc. Dieses Synonym ist für alle Werkzeuge verwendbar, die Standardaustausch durchführen
von malloc-bezogenen Funktionen (zB memcheck, massif, drd, helgrind, exp-dhat,
exp-sgcheck).

· Alternative malloc-Bibliothek: um die malloc-bezogenen Funktionen in einer alternativen zu ersetzen
Bibliothek mit soname mymalloclib.so, gib die wahl
--soname-synonyms=somalloc=mymalloclib.so. Ein Muster kann verwendet werden, um mehrere abzugleichen
Bibliotheken sonamen. Zum Beispiel, --soname-synonyms=somalloc=*tcmalloc* passt auf
der Soname aller Varianten der tcmalloc-Bibliothek (native, debug, profiliert, ...
tcmalloc-Varianten).

Hinweis: Der Soname einer gemeinsam genutzten Elf-Bibliothek kann mit dem readelf abgerufen werden
Dienstprogramm.

· Ersetzungen in einer statisch gelinkten Bibliothek erfolgen mit Hilfe der NONE Muster.
Zum Beispiel, wenn Sie mit verlinken libtcmalloc.a, Memcheck funktioniert ordnungsgemäß, wenn Sie
gib die wahl --soname-synonyms=somalloc=NONE. Beachten Sie, dass ein NONE-Muster
mit der ausführbaren Hauptdatei und jeder gemeinsam genutzten Bibliothek ohne Soname übereinstimmen.

· Um einen "Standard"-Firefox-Build für Linux auszuführen, in dem JEMalloc mit dem verknüpft ist
ausführbare Hauptdatei, verwenden --soname-synonyms=somalloc=NONE.

FEHLERBEHEBUNG VALGRIND OPTIONAL

Es gibt auch einige Optionen zum Debuggen von Valgrind selbst. Sie sollten sie nicht brauchen
im normalen Lauf der Dinge. Wenn Sie die Liste sehen möchten, verwenden Sie die --help-debug .

MEMCHECK OPTIONAL

--leak-check= [Ursprünglich: Zusammenfassung]
Wenn diese Option aktiviert ist, suchen Sie nach Speicherlecks, wenn das Clientprogramm beendet ist. Wenn auf eingestellt
Zusammenfassung, es gibt an, wie viele Lecks aufgetreten sind. Wenn auf eingestellt voller or ja, jedes einzelne Leck
wird im Detail angezeigt und/oder als Fehler gezählt, wie in den Optionen angegeben
--show-leck-arten und --errors-for-leak-arts.

--leak-resolution= [Ursprünglich: hoch]
Bestimmt bei der Dichtheitsprüfung, wie bereit Memcheck ist, andere zu berücksichtigen
Backtraces müssen gleich sein, um mehrere Lecks zu einem einzigen zusammenzuführen
Leckmeldung. Bei Einstellung auf niedrig, müssen nur die ersten beiden Einträge übereinstimmen. Wann vonvier
Einträge müssen übereinstimmen. Wann Highs, müssen alle Einträge übereinstimmen.

Für das Debugging von Hardcore-Lecks möchten Sie wahrscheinlich verwenden --leak-resolution=hoch gemeinsam
mit --num-callers=40 oder eine so große Zahl.

Beachten Sie, dass die --Leckauflösung Die Einstellung hat keinen Einfluss auf die Fähigkeit von Memcheck, zu finden
undicht. Es ändert nur die Darstellung der Ergebnisse.

--show-leak-kinds= [Ursprünglich: definitiv, möglich]
Gibt die Leckarten an, die in a . angezeigt werden sollen voller Lecksuche, auf eine der folgenden Arten:

· eine durch Kommas getrennte Liste von einem oder mehreren von definitiv indirekte möglich erreichbar.

· alle um das komplette Set (alle Leckarten) zu spezifizieren. Es ist äquivalent zu
--show-leak-kinds=definitiv,indirekt,möglich,erreichbar.

· keine für die leere Menge.

--errors-for-leak-kinds= [Ursprünglich: definitiv, möglich]
Gibt die Leckarten an, die als Fehler in a gezählt werden sollen voller Lecksuche. Die is
ähnlich angegeben wie --show-leck-arten

--leak-check-heuristics= [Ursprünglich: alle]
Gibt den Satz von Heuristiken für die Leckprüfung an, der bei der Suche nach Lecks verwendet werden soll. Die
Heuristiken steuern, welche inneren Zeiger auf einen Block bewirken, dass er als
erreichbar. Die heuristische Menge wird auf eine der folgenden Arten angegeben:

· eine durch Kommas getrennte Liste von einem oder mehreren von Standardzeichenfolge Länge64 neues Array
Mehrfachvererbung.

· alle um den kompletten Satz von Heuristiken zu aktivieren. Es ist äquivalent zu
--leak-check-heuristics=stdstring,length64,newarray,multipleinheritance.

· keine für die leere Menge.

Beachten Sie, dass diese Heuristiken vom Layout der Objekte abhängen, die von der
C++-Compiler. Sie wurden mit einigen gcc-Versionen (zB 4.4 und 4.7) getestet. Sie
funktioniert möglicherweise nicht richtig mit anderen C++-Compilern.

--show-reachable= , --show-possably-lost=
Diese Optionen bieten eine alternative Möglichkeit, die anzuzeigenden Leckarten anzugeben:

· --show-reachable=nein --show-possably-lost=yes entspricht
--show-leak-kinds=definite,möglich.

· --show-reachable=nein --show-possably-lost=no entspricht
--show-leak-kinds=definit.

· --show-reachable=ja entspricht --show-leak-kinds=all.

Beachten Sie, dass --show-possably-lost=no hat keine Auswirkung, wenn --show-reachable=ja angegeben.

--undef-value-errors= [Ursprünglich: Jawohl]
Steuert, ob Memcheck die Verwendung von Fehlern mit undefinierten Werten meldet. Setzen Sie dies auf nicht if
Sie möchten keine undefinierten Wertfehler sehen. Es hat auch den Nebeneffekt der Geschwindigkeitsüberschreitung
Memcheck etwas auf.

--track-origins= [Ursprünglich: Nein]
Steuert, ob Memcheck den Ursprung nicht initialisierter Werte verfolgt. Standardmäßig ist es
nicht, was bedeutet, dass, obwohl es Ihnen sagen kann, dass ein nicht initialisierter Wert ist
auf gefährliche Weise verwendet wird, kann es Ihnen nicht sagen, woher der nicht initialisierte Wert stammt
von. Dies macht es oft schwierig, das Wurzelproblem aufzuspüren.

Wenn auf eingestellt ja, verfolgt Memcheck die Herkunft aller nicht initialisierten Werte.
Wenn dann ein nicht initialisierter Wertfehler gemeldet wird, versucht Memcheck, den
Herkunft des Wertes. Ein Ursprung kann einer der folgenden vier Orte sein: ein Heap-Block,
eine Stack-Zuweisung, eine Client-Anfrage oder verschiedene andere Quellen (z. B. ein Aufruf an
brk).

Bei nicht initialisierten Werten, die aus einem Heap-Block stammen, zeigt Memcheck an, wo der Block
vergeben wurde. Für nicht initialisierte Werte, die aus einer Stack-Zuordnung stammen, muss Memcheck
kann Ihnen sagen, welche Funktion den Wert zugewiesen hat, aber nicht mehr - normalerweise ist es
zeigt Ihnen die Quellposition der öffnenden Klammer der Funktion. Also sollten Sie
Überprüfen Sie sorgfältig, ob alle lokalen Variablen der Funktion richtig initialisiert sind.

Performance-Overhead: Ursprungsverfolgung ist teuer. Es halbiert die Geschwindigkeit von Memcheck und
erhöht die Speichernutzung um mindestens 100 MB und möglicherweise mehr. Trotzdem kann es
Reduzieren Sie drastisch den Aufwand, um die Ursache von nicht initialisierten
Wert Fehler, und so ist oft ein Produktivitätsgewinn für Programmierer, obwohl sie mehr laufen
langsam.

Genauigkeit: Memcheck verfolgt die Ursprünge ziemlich genau. Um sehr großen Raum und Zeit zu vermeiden
Gemeinkosten werden einige Näherungen vorgenommen. Es ist möglich, wenn auch unwahrscheinlich, dass
Memcheck meldet eine falsche Herkunft oder kann keine Herkunft feststellen.

Beachten Sie, dass die Kombination --track-origins=ja und --undef-value-errors=nein is
unsinnig. Memcheck prüft diese Kombination beim Start und lehnt sie ab.

--partial-loads-ok= [Ursprünglich: Jawohl]
Steuert, wie Memcheck 32-, 64-, 128- und 256-Bit natürlich ausgerichtete Lasten von . verarbeitet
Adressen, für die einige Bytes adressierbar sind und andere nicht. Wann ja, eine solche
Ladevorgänge erzeugen keinen Adressfehler. Stattdessen werden geladene Bytes aus illegalem
Adressen werden als nicht initialisiert markiert, und diejenigen, die legalen Adressen entsprechen, sind
normal gehandhabt.

Wann nicht, Ladevorgänge von teilweise ungültigen Adressen werden genauso behandelt wie Ladevorgänge von
völlig ungültige Adressen: Es wird ein Fehler bei einer ungültigen Adresse ausgegeben, und das resultierende
Bytes werden als initialisiert markiert.

Beachten Sie, dass Code, der sich auf diese Weise verhält, gegen die ISO C/C++-Standards verstößt.
und sollte als gebrochen angesehen werden. Wenn möglich, sollte ein solcher Code behoben werden.

--teure-definedness-checks= [Ursprünglich: Nein]
Steuert, ob Memcheck genauere aber auch teurere (Zeit
verbrauchende) Algorithmen bei der Überprüfung der Definiertheit eines Wertes. Die Standardeinstellung ist
das nicht zu tun und es ist normalerweise ausreichend. Für stark optimierten Code
valgrind kann sich manchmal fälschlicherweise beschweren. Valgrind aufrufen mit
--expensive-definedness-checks=yes hilft, kostet aber die Leistung. Laufzeit
eine Verschlechterung von 25 % wurde beobachtet, aber die zusätzlichen Kosten hängen stark von der
Anwendung zur Hand.

--keep-stacktraces=alloc|free|alloc-and-free|alloc-then-free|none [Ursprünglich:
alloc-and-free]
Steuert, welche Stack-Trace(s) für mallocierte und/oder befreite Blöcke aufbewahrt werden sollen.

Bei alloc-dann-frei, wird zum Zeitpunkt der Zuweisung ein Stack-Trace aufgezeichnet und zugeordnet
mit dem Block. Wenn der Block freigegeben wird, wird ein zweiter Stack-Trace aufgezeichnet, und dieser
ersetzt den Allokations-Stack-Trace. Infolgedessen können alle "use after free"-Fehler in Bezug auf
zu diesem Block kann nur einen Stack-Trace für die Stelle anzeigen, an der der Block freigegeben wurde.

Bei alloc-and-free, sowohl Zuweisungs- als auch Aufhebungs-Stack-Traces für den Block
sind gelagert. Daher zeigt ein "use after free"-Fehler beides an, was den Fehler verursachen kann
einfacher zu diagnostizieren. Im Vergleich zu alloc-dann-frei, diese Einstellung erhöht sich leicht
Die Speichernutzung von Valgrind als Block enthält zwei Referenzen statt einer.

Bei zuweisen, wird nur der Allokations-Stack-Trace aufgezeichnet (und gemeldet). Mit kostenlos,
nur der Deployment-Stack-Trace wird aufgezeichnet (und gemeldet). Diese Werte etwas
Verringern Sie die Speicher- und CPU-Auslastung von Valgrind. Sie können je nach Fehler nützlich sein
Typen, nach denen Sie suchen, und den Detaillierungsgrad, den Sie für ihre Analyse benötigen. Zum
Wenn Sie beispielsweise nur an Speicherleckfehlern interessiert sind, reicht es aus, aufzuzeichnen
die Zuordnungs-Stack-Traces.

Bei keine, werden keine Stack-Traces für malloc- und free-Operationen aufgezeichnet. Wenn dein
Programm allokiert viele Blöcke und/oder allokiert/freit von vielen verschiedenen Stack
Spuren, dies kann die benötigte CPU und/oder den Arbeitsspeicher erheblich verringern. Natürlich wenige
Details zu Fehlern im Zusammenhang mit Heap-Blöcken werden gemeldet.

Beachten Sie, dass Valgrind, sobald ein Stack-Trace aufgezeichnet wurde, den Stack-Trace im Speicher behält
auch wenn es von keinem Block referenziert wird. Einige Programme (zum Beispiel rekursive
Algorithmen) können eine große Anzahl von Stack-Traces generieren. Wenn Valgrind zu viel verwendet
Speicher unter solchen Umständen können Sie den benötigten Speicher mit den Optionen reduzieren
--keep-stacktraces und/oder indem Sie einen kleineren Wert für die Option verwenden --num-Anrufer.

--freelist-vol= [Ursprünglich: 20000000]
Wenn das Client-Programm Speicher mit . freigibt kostenlos (in C) oder löschen (C++), diesen Speicher
nicht sofort für eine Neuzuweisung zur Verfügung gestellt wird. Stattdessen ist es markiert
unzugänglich und in eine Warteschlange von freigegebenen Blöcken gestellt. Der Zweck ist, so lange aufzuschieben, wie
der Punkt, an dem frei gewordener Speicher wieder in Umlauf kommt. Dies
erhöht die Chance, dass Memcheck ungültige Zugriffe auf Blöcke erkennen kann
für einen längeren Zeitraum nach ihrer Freilassung.

Diese Option gibt die maximale Gesamtgröße der Blöcke in der Warteschlange in Byte an.
Der Standardwert beträgt zwanzig Millionen Byte. Wenn Sie diesen erhöhen, erhöht sich der Gesamtbetrag
des von Memcheck verwendeten Speichers, erkennt jedoch möglicherweise ungültige Verwendungen von freigegebenen Blöcken, die
sonst unentdeckt bleiben.

--freelist-big-blocks= [Ursprünglich: 1000000]
Wenn Blöcke aus der Warteschlange der freigegebenen Blöcke für die Neuzuweisung verfügbar gemacht werden,
Memcheck rezirkuliert vorrangig die Blöcke mit einer Größe größer oder gleich
--freelist-big-blocks. Dadurch wird sichergestellt, dass das Freigeben von großen Blöcken (insbesondere das Freigeben von
Blöcke größer als --freelist-vol) führt nicht sofort zu einer Rezirkulation von
alle (oder viele) der kleinen Blöcke in der freien Liste. Mit anderen Worten, diese Option
erhöht die Wahrscheinlichkeit, baumelnde Zeiger für die "kleinen" Blöcke zu entdecken, sogar
wenn große Blöcke freigegeben werden.

Ein Wert von 0 bedeutet, dass alle Blöcke in einer FIFO-Reihenfolge rezirkuliert werden.

--workaround-gcc296-bugs= [Ursprünglich: Nein]
Wenn diese Option aktiviert ist, gehen Sie davon aus, dass in geringem Abstand unterhalb des Stack-Zeigers gelesen und geschrieben wird
sind auf Fehler in GCC 2.96 zurückzuführen und werden nicht gemeldet. Der "kleine Abstand" beträgt 256
Bytes standardmäßig. Beachten Sie, dass GCC 2.96 der Standard-Compiler auf einigen alten Linux ist
Distributionen (RedHat 7.X) und daher müssen Sie diese Option möglicherweise verwenden. Verwenden Sie es nicht, wenn
Sie müssen nicht, da es dazu führen kann, dass echte Fehler übersehen werden. Eine bessere Alternative
besteht darin, einen neueren GCC zu verwenden, in dem dieser Fehler behoben ist.

Möglicherweise müssen Sie diese Option auch verwenden, wenn Sie mit GCC 3.X oder 4.X auf 32-Bit arbeiten
PowerPC-Linux. Dies liegt daran, dass GCC Code generiert, der gelegentlich auf unten zugreift
der Stapelzeiger, insbesondere für Gleitkomma-zu/von-Integer-Konvertierungen. Dies
verstößt gegen die 32-Bit-PowerPC-ELF-Spezifikation, die keine Vorkehrungen für
Stellen unterhalb des Stack-Zeigers zugänglich sein.

--show-mismatched-frees= [Ursprünglich: Jawohl]
Wenn aktiviert, überprüft Memcheck, ob Heap-Blöcke mit einer Funktion freigegeben wurden, die
entspricht der Zuordnungsfunktion. Das heißt, es erwartet kostenlos verwendet werden, um die Zuordnung aufzuheben
Blöcke zugewiesen von malloc, löschen für Blöcke zugewiesen von neusowie löschen[] für
Blöcke zugewiesen von Neu[]. Wenn eine Abweichung festgestellt wird, wird ein Fehler gemeldet. Das ist in
allgemein wichtig, da in einigen Umgebungen das Freigeben mit einer nicht übereinstimmenden Funktion
kann zu Abstürzen führen.

Es gibt jedoch ein Szenario, in dem solche Inkongruenzen nicht vermieden werden können. Das ist, wenn die
Benutzer bietet Implementierungen von neu/Neu[] dieser Anruf malloc und löschen/löschen[]
dieser Anruf kostenlos, und diese Funktionen sind asymmetrisch inline. Stellen Sie sich zum Beispiel vor
zur Abwicklung, Integrierung, Speicherung und löschen[] ist inline aber Neu[] ist nicht. Das Ergebnis ist, dass Memcheck alles "sieht"
löschen[] Anrufe als Direktanrufe an kostenlos, auch wenn die Programmquelle keine
nicht übereinstimmende Anrufe.

Dies führt zu vielen verwirrenden und irrelevanten Fehlermeldungen.
--show-mismatched-frees=nein deaktiviert diese Prüfungen. Es ist im Allgemeinen nicht ratsam,
deaktivieren Sie sie jedoch, da Sie dadurch möglicherweise echte Fehler übersehen.

--ignore-ranges=0xPP-0xQQ[,0xRR-0xSS]
Alle in dieser Option aufgeführten Bereiche (und es können mehrere Bereiche angegeben werden, getrennt durch
Kommas) werden von der Adressierbarkeitsprüfung von Memcheck ignoriert.

--malloc-fill=
Füllt Blöcke, die von malloc, new usw. zugewiesen wurden, aber nicht von calloc, mit dem angegebenen
Byte. Dies kann nützlich sein, wenn Sie versuchen, obskure Speicherbeschädigungsprobleme auszumerzen.
Der zugewiesene Bereich wird von Memcheck immer noch als undefiniert angesehen -- nur diese Option
wirkt sich auf seinen Inhalt aus. Beachten Sie, dass --malloc-fill wirkt sich nicht auf einen Speicherblock aus, wenn
es wird als Argument für Client-Anfragen verwendet VALGRIND_MEMPOOL_ALLOC oder
VALGRIND_MALLOCLIKE_BLOCK.

--free-fill=
Füllt Blöcke, die durch free, delete usw. freigegeben wurden, mit dem angegebenen Byte-Wert. Das kann sein
nützlich, wenn Sie versuchen, obskure Speicherbeschädigungsprobleme auszumerzen. Der freigegebene Bereich ist
wird von Memcheck immer noch als nicht gültig für den Zugriff angesehen -- diese Option betrifft nur seine
Inhalt. Beachten Sie, dass --free-fill wirkt sich nicht auf einen Speicherblock aus, wenn er als
Argument für Clientanforderungen VALGRIND_MEMPOOL_FREE oder VALGRIND_FREELIKE_BLOCK.

CACHEGRIND OPTIONAL

--I1= , , Größe>
Geben Sie die Größe, Assoziativität und Zeilengröße des Level-1-Befehlscache an.

--D1= , , Größe>
Geben Sie die Größe, Assoziativität und Zeilengröße des Level-1-Datencaches an.

--LL= , , Größe>
Geben Sie die Größe, Assoziativität und Zeilengröße des Last-Level-Cache an.

--cache-sim=no|ja [Ja]
Aktiviert oder deaktiviert die Erfassung von Cache-Zugriffs- und Fehltrefferzählungen.

--branch-sim=nein|ja [Nein]
Aktiviert oder deaktiviert die Erfassung von Verzweigungsbefehls- und Fehlvorhersagezählungen. Von
Standardmäßig ist dies deaktiviert, da es Cachegrind um etwa 25 % verlangsamt. Beachten Sie, dass
du kannst nicht angeben --cache-sim=nein und --branch-sim=nein zusammen, als würde das gehen
Cachegrind ohne zu sammelnde Informationen.

--cachegrind-out-file=
Schreiben Sie die Profildaten in eine Datei und nicht in die Standardausgabedatei.
cachegrind.out. . Die %p und %q Formatbezeichner können verwendet werden, um den Prozess einzubetten
ID und/oder der Inhalt einer Umgebungsvariablen im Namen, wie bei der
Kernoption --Logdatei.

ANRUFGRIND OPTIONAL

--callgrind-out-file=
Schreiben Sie die Profildaten in eine Datei und nicht in die Standardausgabedatei.
callgrind.out. . Die %p und %q Formatbezeichner können verwendet werden, um den Prozess einzubetten
ID und/oder der Inhalt einer Umgebungsvariablen im Namen, wie bei der
Kernoption --Logdatei. Wenn mehrere Dumps erstellt werden, wird der Dateiname geändert
weiter; siehe unten.

--dump-line= [Ursprünglich: Jawohl]
Dies gibt an, dass die Ereigniszählung mit der Granularität der Quellzeilen durchgeführt werden soll.
Dies ermöglicht eine Quellenanmerkung für Quellen, die mit Debug-Informationen kompiliert sind
(-g).

--dump-instr= [Ursprünglich: Nein]
Dies gibt an, dass die Ereigniszählung mit Anweisungsgranularität durchgeführt werden soll.
Dies ermöglicht eine Assembly-Code-Annotation. Aktuell können die Ergebnisse nur angezeigt werden
von KCachegrind.

--compress-strings= [Ursprünglich: Jawohl]
Diese Option beeinflusst das Ausgabeformat der Profildaten. Es gibt an, ob
Strings (Datei- und Funktionsnamen) sollten durch Zahlen identifiziert werden. Das schrumpft
Datei, aber erschwert es Menschen, sie zu lesen (was in keiner
Fall).

--compress-pos= [Ursprünglich: Jawohl]
Diese Option beeinflusst das Ausgabeformat der Profildaten. Es gibt an, ob
Zahlenpositionen werden immer als Absolutwerte angegeben oder dürfen
relativ zu den vorherigen Zahlen. Dadurch wird die Dateigröße verkleinert.

--combine-dumps= [Ursprünglich: Nein]
Wenn aktiviert, wenn mehrere Profildatenteile generiert werden sollen, werden diese Teile
an dieselbe Ausgabedatei angehängt. Nicht empfohlen.

--dump-every-bb= [Ursprünglich: 0, noch nie]
Profildaten alle ausgeben zählen grundlegende Blöcke. Ob ein Dump benötigt wird, wird nur geprüft
wenn der interne Scheduler von Valgrind ausgeführt wird. Daher ist die sinnvolle Mindesteinstellung
etwa 100000. Der Zähler ist ein 64-Bit-Wert, um lange Dump-Perioden zu ermöglichen.

--dump-before=
Dump beim Betreten Funktion.

--zero-before=
Null alle Kosten bei der Eingabe Funktion.

--dump-after=
Dump beim Verlassen Funktion.

--instr-atstart= [Ursprünglich: Jawohl]
Geben Sie an, ob Callgrind die Simulation und Profilerstellung von Anfang an starten soll
das Programm. Wenn auf no gesetzt, kann Callgrind keine Informationen sammeln,
einschließlich Anrufe, aber es wird höchstens eine Verlangsamung von etwa 4 haben, was das Minimum ist
Valgrind über Kopf. Instrumentierung kann interaktiv über callgrind_control aktiviert werden
-ich an.

Beachten Sie, dass das resultierende Anrufdiagramm höchstwahrscheinlich kein . enthält Haupt-, aber wird
enthalten alle Funktionen, die nach der Aktivierung der Instrumentierung ausgeführt wurden. Instrumentierung
kann auch programmgesteuert aktiviert/deaktiviert werden. Siehe die Callgrind-Include-Datei callgrind.h
für das Makro müssen Sie in Ihrem Quellcode verwenden.

Bei Cache-Simulationen sind die Ergebnisse beim Einschalten der Instrumentierung weniger genau
später im Programmlauf, da der Simulator in diesem Moment mit leerem Cache startet.
Schalten Sie die Ereignissammlung später ein, um diesen Fehler zu beheben.

--collect-atstart= [Ursprünglich: Jawohl]
Geben Sie an, ob die Ereignissammlung zu Beginn der Profilausführung aktiviert ist.

Um nur Teile Ihres Programms zu betrachten, haben Sie zwei Möglichkeiten:

1. Ereigniszähler auf Null setzen, bevor Sie den Programmteil eingeben, den Sie profilieren möchten, und ausgeben
das Ereignis zählt zu einer Datei, nachdem dieser Programmteil verlassen wurde.

2. Schalten Sie den Erfassungsstatus nach Bedarf ein/aus, um nur Ereigniszähler anzuzeigen.
während Sie sich innerhalb des Programmteils befinden, das Sie profilieren möchten.

Die zweite Option kann verwendet werden, wenn der Programmteil, den Sie profilieren möchten, viele heißt
mal. Option 1, dh viele Dumps zu erstellen, ist hier nicht praktikabel.

Der Sammlungsstatus kann beim Betreten und Verlassen einer bestimmten Funktion mit der Option . umgeschaltet werden
--toggle-sammeln. Wenn Sie diese Option verwenden, sollte der Sammlungsstatus deaktiviert werden
Anfang. Beachten Sie, dass die Spezifikation von --toggle-sammeln setzt implizit
--collect-state=nein.

Der Sammlungsstatus kann auch durch Einfügen der Client-Anfrage umgeschaltet werden
CALLGRIND_TOGGLE_COLLECT ; an den benötigten Codestellen.

--toggle-collect=
Sammlung bei Eintritt/Austritt umschalten Funktion.

--collect-jumps= [Ursprünglich: Nein]
Damit wird festgelegt, ob Informationen für (bedingte) Sprünge gesammelt werden sollen. Wie
oben, callgrind_annotate ist derzeit nicht in der Lage, Ihnen die Daten anzuzeigen. Sie müssen verwenden
KCachegrind, um Sprungpfeile im annotierten Code zu erhalten.

--collect-systime= [Ursprünglich: Nein]
Damit wird festgelegt, ob Informationen zu Systemaufrufzeiten gesammelt werden sollen.

--collect-bus= [Ursprünglich: Nein]
Damit wird festgelegt, ob die Anzahl der ausgeführten globalen Busereignisse gesammelt werden soll.
Für diese Ereignisse wird der Ereignistyp "Ge" verwendet.

--cache-sim= [Ursprünglich: Nein]
Geben Sie an, ob Sie eine vollständige Cache-Simulation durchführen möchten. Standardmäßig wird nur Anweisung gelesen
Zugriffe werden gezählt ("Ir"). Bei Cache-Simulation sind weitere Ereigniszähler
aktiviert: Cache-Misses bei Instruktionslesevorgängen ("I1mr"/"ILmr"), Datenlesezugriffen ("Dr")
und zugehörige Cache-Fehltreffer ("D1mr"/"DLmr"), Datenschreibzugriffe ("Dw") und zugehöriger Cache
verfehlt ("D1mw"/"DLmw"). Weitere Informationen finden Sie unter Cachegrind: ein Cache und Zweig-
Vorhersage-Profiler.

--branch-sim= [Ursprünglich: Nein]
Geben Sie an, ob Sie eine Simulation der Verzweigungsvorhersage durchführen möchten. Weitere Ereigniszähler sind
aktiviert: Anzahl ausgeführter bedingter Verzweigungen und zugehöriger Prädiktor-Fehltreffer
("Bc"/"Bcm"), ausgeführte indirekte Sprünge und damit verbundene Fehlschläge des Sprungadressen-Prädiktors
("Bi"/"Bim").

HELGRIND OPTIONAL

--free-is-write=nein|ja [Ursprünglich: Nein]
Wenn aktiviert (nicht die Standardeinstellung), behandelt Helgrind das Freigeben von Heap-Speicher so, als ob das
Speicher wurde unmittelbar vor dem freien geschrieben. Dies entlarvt Rassen, bei denen das Gedächtnis ist
von einem Thread referenziert und von einem anderen freigegeben, aber es gibt kein Observable
Synchronisationsereignis, um sicherzustellen, dass der Verweis vor dem free.

Diese Funktionalität ist neu in Valgrind 3.7.0 und gilt als experimentell. es ist
nicht standardmäßig aktiviert, da die Interaktion mit benutzerdefinierten Speicherzuweisungen nicht möglich ist
derzeit gut verstanden. Benutzer-Feedback ist willkommen.

--track-lockorders=nein|ja [Ursprünglich: Jawohl]
Wenn aktiviert (Standardeinstellung), führt Helgrind eine Konsistenzprüfung der Sperrreihenfolge durch. Zum
Bei einigen fehlerhaften Programmen kann die große Anzahl der gemeldeten Sperrreihenfolgefehler zu
ärgerlich, besonders wenn Sie nur an Rennfehlern interessiert sind. Sie können daher
finde es hilfreich, die Überprüfung der Sperrreihenfolge zu deaktivieren.

--history-level=none|ungefähr|voll [Ursprünglich: voll]
--history-level=voll (die Standardeinstellung) bewirkt, dass Helgrind genügend Informationen sammelt über
"alt" greift zu, dass es zwei Stack-Traces in einem Race-Report erzeugen kann - beide den Stack
Trace für den aktuellen Zugriff und Trace für den älteren, widersprüchlichen Zugriff. Zu
Speichernutzung begrenzen, "alte" Zugriffe Stacktraces sind auf maximal 8 Einträge beschränkt,
selbst wenn --num-Anrufer Wert ist größer.

Das Sammeln solcher Informationen ist sowohl in Bezug auf Geschwindigkeit als auch Speicher teuer, insbesondere für
Programme, die viele Synchronisierungsereignisse zwischen Threads durchführen (Sperren, Entsperren usw.).
Ohne solche Informationen ist es schwieriger, die Ursachen von Rassen aufzuspüren.
Trotzdem benötigen Sie es möglicherweise nicht in Situationen, in denen Sie nur nach dem suchen möchten
Vorhandensein oder Fehlen von Rassen, zum Beispiel bei der Durchführung von Regressionstests von a
bisher rennfreies Programm.

--history-level=keine ist das entgegengesetzte Extrem. Es führt dazu, dass Helgrind keine sammelt
Informationen zu früheren Zugriffen. Dies kann dramatisch schneller sein als
--history-level=voll.

--history-level=ungefähr bietet einen Kompromiss zwischen diesen beiden Extremen. Es verursacht
Helgrind, um eine vollständige Spur für den späteren Zugriff anzuzeigen, und ungefähre Informationen
bezüglich des früheren Zugangs. Diese ungefähren Informationen bestehen aus zwei Stapeln, und
der frühere Zugriff erfolgt garantiert irgendwo zwischen Programmpunkten
durch die beiden Stapel gekennzeichnet. Dies ist nicht so nützlich wie das Anzeigen des genauen Stapels für die
vorheriger Zugriff (wie --history-level=voll tut), aber es ist besser als nichts, und es
ist fast so schnell wie --history-level=keine.

--conflict-cache-size=N [Ursprünglich: 1000000]
Dieses Flag hat nur Wirkung bei --history-level=voll.

Informationen über "alte" widersprüchliche Zugriffe werden in einem Cache begrenzter Größe gespeichert,
mit LRU-ähnlicher Verwaltung. Dies ist notwendig, da es nicht praktikabel ist, a
Stacktrace für jeden einzelnen Speicherzugriff des Programms. Historische Informationen
an Orten, auf die nicht kürzlich zugegriffen wurde, wird regelmäßig verworfen, um Speicherplatz im
Zwischenspeicher.

Diese Option steuert die Größe des Caches in Bezug auf die Anzahl der verschiedenen Speicher
Adressen, für die widersprüchliche Zugangsinformationen gespeichert sind. Wenn du das findest
Helgrind zeigt Race-Fehler mit nur einem Stack anstelle der erwarteten zwei an
Stapel, versuchen Sie, diesen Wert zu erhöhen.

Der Mindestwert beträgt 10,000 und der Höchstwert 30,000,000 (dreißigmal der Standardwert).
Wert). Das Erhöhen des Wertes um 1 erhöht den Speicherbedarf von Helgrind um sehr
ungefähr 100 Byte, so dass der Maximalwert leicht drei zusätzliche Gigabyte oder so frisst
der Erinnerung.

--check-stack-refs=nein|ja [Ursprünglich: Jawohl]
Standardmäßig prüft Helgrind alle Datenspeicherzugriffe Ihres Programms. Diese Flagge
ermöglicht es Ihnen, die Prüfung auf Zugriffe auf Thread-Stacks (lokale Variablen) zu überspringen. Das kann
die Leistung zu verbessern, geht jedoch auf Kosten fehlender Races bei den Stack-zugewiesenen Daten.

--ignore-thread-creation= [Ursprünglich: Nein]
Steuert, ob alle Aktivitäten während der Thread-Erstellung ignoriert werden sollen. Standardmäßig
nur auf Solaris aktiviert. Solaris bietet höheren Durchsatz, Parallelität und
Skalierbarkeit als bei anderen Betriebssystemen, auf Kosten feinkörnigerer Sperren
Aktivität. Das bedeutet zum Beispiel, dass beim Erstellen eines Threads unter glibc nur ein
big lock wird für alle Thread-Setups verwendet. Solaris libc verwendet mehrere feingranulare Sperren
und der Ersteller-Thread nimmt seine Aktivitäten so schnell wie möglich wieder auf, beispielsweise verlässt er ihn
Stack und TLS-Setup-Sequenz zum erstellten Thread. Diese Situation verwirrt Helgrind
Es wird davon ausgegangen, dass zwischen Schöpfer und Erschaffenem eine falsche Reihenfolge besteht
Gewinde; und daher wären viele Arten von Race-Bedingungen in der Anwendung nicht möglich
berichtet. Um eine solche falsche Reihenfolge zu verhindern, wird diese Befehlszeilenoption auf yes gesetzt von
Standard auf Solaris. Alle Aktivitäten (Laden, Speichern, Client-Anfragen) werden daher ignoriert
während:

· Aufruf von pthread_create() im Ersteller-Thread

· Thread-Erstellungsphase (Stack- und TLS-Setup) im erstellten Thread

Auch neuer Speicher, der während der Thread-Erstellung zugewiesen wurde, wird nicht nachverfolgt, das heißt Race-Reporting
wird dort unterdrückt. DRD macht implizit dasselbe. Dies ist notwendig, weil
Solaris libc speichert viele Objekte im Cache und verwendet sie für verschiedene Threads wieder und das
verwirrt Helgrind.

DRD OPTIONAL

--check-stack-var= [Ursprünglich: Nein]
Steuert, ob DRD Data Races auf Stack-Variablen erkennt. Stack-Variablen überprüfen
ist standardmäßig deaktiviert, da die meisten Programme Stack-Variablen nicht weitergeben
Threads.

--exclusive-threshold= [Ursprünglich: aus]
Drucken Sie eine Fehlermeldung, wenn eine Mutex- oder Writer-Sperre länger als die Zeit gehalten wurde
in Millisekunden angegeben. Diese Option aktiviert die Erkennung von Sperrenkonflikten.

--join-list-vol= [Ursprünglich: 10]
Datenrennen, die zwischen einer Anweisung am Ende eines Threads und einem anderen Thread auftreten
kann übersehen werden, wenn die Speicherzugriffsinformationen sofort nach dem Ausführen eines Threads verworfen werden
beigetreten ist. Mit dieser Option kann angegeben werden, für wie viele verbundene Threads Speicher
Zugangsdaten sollten aufbewahrt werden.

--first-race-only= [Ursprünglich: Nein]
Ob nur das erste Datenrennen gemeldet werden soll, das an einem Speicherort erkannt wurde
oder alle Datenrennen, die an einem Speicherort erkannt wurden.

--free-is-write= [Ursprünglich: Nein]
Ob Wettläufe zwischen dem Zugriff auf den Speicher und der Freigabe von Speicher gemeldet werden sollen. Dies aktivieren
Option kann dazu führen, dass DRD etwas langsamer ausgeführt wird. Anmerkungen:

· Aktivieren Sie diese Option nicht, wenn Sie benutzerdefinierte Speicherzuweisungen verwenden, die die
VG_USERREQ__MALLOCLIKE_BLOCK und VG_USERREQ__FREELIKE_BLOCK weil das wäre
zu falsch positiven Ergebnissen führen.

· Aktivieren Sie diese Option nicht, wenn Sie Objekte mit Referenzzählung verwenden, da dies
zu falsch positiven Ergebnissen führen, selbst wenn dieser Code richtig mit annotiert wurde
ANNOTATE_HAPPENS_BEFORE und ANNOTATE_HAPPENS_AFTER. Siehe zB die Ausgabe der
folgender Befehl als Beispiel: valgrind --tool=drd --free-is-write=yes
drd/tests/annotate_smart_pointer.

--report-signal-unlocked= [Ursprünglich: Jawohl]
Ob Anrufe an gemeldet werden sollen pthread_cond_signal und pthread_cond_broadcast wo die
Mutex verbunden mit dem Signal durch pthread_cond_wait or
pthread_cond_timed_waitist zum Zeitpunkt des Sendens des Signals nicht gesperrt. Ein Signal senden
ohne den zugehörigen Mutex zu sperren, ist ein häufiger Programmierfehler, der
zu subtilen Racebedingungen und unvorhersehbarem Verhalten führen. Es gibt einige ungewöhnliche
Synchronisationsmuster, bei denen es jedoch sicher ist, ein Signal zu senden, ohne a . zu halten
den zugehörigen Mutex sperren.

--segment-merging= [Ursprünglich: Jawohl]
Steuert das Zusammenführen von Segmenten. Das Zusammenführen von Segmenten ist ein Algorithmus zur Begrenzung der Speichernutzung der
Algorithmus zur Erkennung von Datenrassen. Das Deaktivieren der Segmentzusammenführung kann die Genauigkeit von
die sogenannten 'anderen Segmente', die in Rennberichten angezeigt werden, aber auch ein Out auslösen können
des Speicherfehlers.

--segment-merging-interval= [Ursprünglich: 10]
Führen Sie das Zusammenführen von Segmenten erst durch, nachdem die angegebene Anzahl neuer Segmente abgeschlossen wurde
erstellt. Dies ist eine erweiterte Konfigurationsoption, mit der Sie wählen können, ob Sie
Minimieren Sie die Speichernutzung von DRD, indem Sie einen niedrigen Wert wählen oder um DRD schneller laufen zu lassen um
einen etwas höheren Wert wählen. Der optimale Wert für diesen Parameter hängt von der
Programm analysiert. Der Standardwert funktioniert für die meisten Programme gut.

--shared-threshold= [Ursprünglich: aus]
Drucken Sie eine Fehlermeldung, wenn eine Lesesperre länger als die angegebene Zeit gehalten wurde
(in Millisekunden). Diese Option aktiviert die Erkennung von Sperrenkonflikten.

--show-confl-seg= [Ursprünglich: Jawohl]
Widersprüchliche Segmente in Rennberichten anzeigen. Da diese Informationen helfen können, die
Ursache eines Data Race ist diese Option standardmäßig aktiviert. Das Deaktivieren dieser Option macht
die Ausgabe von DRD kompakter.

--show-stack-usage= [Ursprünglich: Nein]
Druckstapelnutzung beim Thread-Exit-Zeitpunkt. Wenn ein Programm eine große Anzahl von
Threads ist es wichtig, die Menge des zugewiesenen virtuellen Speichers zu begrenzen
Thread-Stapel. Diese Option ermöglicht es zu beobachten, wie viel Stack-Speicher belegt wurde
wird von jedem Thread des Client-Programms verwendet. Hinweis: Das DRD-Tool selbst weist einige zu
temporäre Daten auf dem Client-Thread-Stack. Der Platz, der für diese temporären Daten benötigt wird
muss vom Client-Programm zugewiesen werden, wenn es Stack-Speicher zuweist, ist es aber nicht
in der von DRD gemeldeten Stack-Nutzung enthalten.

--ignore-thread-creation= [Ursprünglich: Nein]
Steuert, ob alle Aktivitäten während der Thread-Erstellung ignoriert werden sollen. Standardmäßig
nur auf Solaris aktiviert. Solaris bietet höheren Durchsatz, Parallelität und
Skalierbarkeit als bei anderen Betriebssystemen, auf Kosten feinkörnigerer Sperren
Aktivität. Das bedeutet zum Beispiel, dass beim Erstellen eines Threads unter glibc nur ein
big lock wird für alle Thread-Setups verwendet. Solaris libc verwendet mehrere feingranulare Sperren
und der Ersteller-Thread nimmt seine Aktivitäten so schnell wie möglich wieder auf, beispielsweise verlässt er ihn
Stack und TLS-Setup-Sequenz zum erstellten Thread. Diese Situation verwirrt DRD, da es
geht davon aus, dass zwischen dem Ersteller und dem erstellten Thread eine falsche Reihenfolge besteht; und
daher würden viele Arten von Wettlaufbedingungen in der Anwendung nicht gemeldet. Zu
Um eine solche falsche Reihenfolge zu verhindern, ist diese Befehlszeilenoption standardmäßig auf yes gesetzt
Solaris. Alle Aktivitäten (Laden, Speichern, Client-Anfragen) werden daher ignoriert während:

· Aufruf von pthread_create() im Ersteller-Thread

· Thread-Erstellungsphase (Stack- und TLS-Setup) im erstellten Thread

--trace-addr= [Ursprünglich: keiner]
Verfolgen Sie alle Lade- und Speicheraktivitäten für die angegebene Adresse. Diese Option kann sein
mehr als einmal angegeben.

--ptrace-addr= [Ursprünglich: keiner]
Verfolgen Sie alle Lade- und Speicheraktivitäten für die angegebene Adresse und machen Sie das auch weiterhin
nachdem der Speicher an dieser Adresse freigegeben und neu zugewiesen wurde.

--trace-alloc= [Ursprünglich: Nein]
Verfolgen Sie alle Speicherzuweisungen und -freigaben. Kann eine riesige Menge an Output produzieren.

--trace-barrier= [Ursprünglich: Nein]
Verfolgen Sie alle Barriereaktivitäten.

--trace-cond= [Ursprünglich: Nein]
Verfolgen Sie alle Aktivitäten der Bedingungsvariablen.

--trace-fork-join= [Ursprünglich: Nein]
Verfolgen Sie alle Thread-Erstellungs- und alle Thread-Beendigungsereignisse.

--trace-hb= [Ursprünglich: Nein]
Trace-Ausführung von ANNOTATE_HAPPENS_BEFORE(), ANNOTATE_HAPPENS_AFTER() und
ANNOTATE_HAPPENS_DONE() Client-Anfragen.

--trace-mutex= [Ursprünglich: Nein]
Verfolgen Sie alle Mutex-Aktivitäten.

--trace-rwlock= [Ursprünglich: Nein]
Verfolgen Sie alle Lese-Schreib-Sperraktivitäten.

--trace-semaphore= [Ursprünglich: Nein]
Verfolgen Sie alle Semaphor-Aktivitäten.

MASSIV OPTIONAL

--heap= [Ursprünglich: Jawohl]
Gibt an, ob eine Heap-Profilerstellung durchgeführt werden soll.

--heap-admin= [Ursprünglich: 8]
Wenn die Heap-Profilerstellung aktiviert ist, wird die Anzahl der administrativen Bytes pro Block an
verwenden. Dies sollte eine Schätzung des Durchschnitts sein, da er variieren kann. Zum Beispiel die
Der von glibc unter Linux verwendete Allocator erfordert zwischen 4 und 15 Bytes pro Block.
abhängig von verschiedenen Faktoren. Dieser Allocator benötigt auch Admin-Speicherplatz für freigegebene
Blöcke, aber Massif kann dies nicht erklären.

--stacks= [Ursprünglich: Nein]
Gibt an, ob Stack-Profiling durchgeführt werden soll. Diese Option verlangsamt Massif
stark und ist daher standardmäßig deaktiviert. Beachten Sie, dass Massif davon ausgeht, dass der Hauptstapel
Größe Null beim Start. Dies ist nicht wahr, aber ansonsten ist es schwierig, dies genau zu tun.
Darüber hinaus zeigt ein Beginn bei Null besser die Größe des Teils des Hauptstapels an
über die ein Benutzerprogramm tatsächlich die Kontrolle hat.

--pages-as-heap= [Ursprünglich: Nein]
Weist Massif an, den Speicher auf Seitenebene und nicht auf dem malloc-Block zu profilieren
Niveau. Details siehe oben.

--Tiefe= [Ursprünglich: 30]
Maximale Tiefe der für detaillierte Snapshots aufgezeichneten Zuordnungsbäume. Erhöhen es
wird Massif etwas langsamer laufen lassen, mehr Speicher verwenden und eine größere Ausgabe erzeugen
Dateien.

--alloc-fn=
Mit dieser Option angegebene Funktionen werden wie ein Heap behandelt
Zuordnungsfunktion wie malloc. Dies ist nützlich für Funktionen, die Wrapper für
malloc or neu, die die Zuordnungsbäume mit uninteressanten Informationen füllen können.
Diese Option kann mehrmals in der Befehlszeile angegeben werden, um mehrere zu benennen
Funktionen.

Beachten Sie, dass die benannte Funktion nur so behandelt wird, wenn sie der oberste Eintrag in a . ist
Stack-Trace oder direkt unter einer anderen auf diese Weise behandelten Funktion. Zum Beispiel, wenn Sie
eine Funktion malloc1 das umhüllt mallocsowie malloc2 das umhüllt malloc1, nur angeben
--alloc-fn=malloc2 wird keine Wirkung haben. Sie müssen angeben --alloc-fn=malloc1 as
Gut. Dies ist ein wenig umständlich, aber der Grund dafür ist, dass die Zuordnung überprüft wird
Funktionen ist langsam und es spart viel Zeit, wenn Massif aufhören kann, durch die
Stack-Trace-Einträge, sobald es einen findet, der nicht übereinstimmt, anstatt zu müssen
weiter durch alle Einträge.

Beachten Sie, dass C++-Namen demangled sind. Beachten Sie auch, dass überladene C++-Namen geschrieben werden müssen
vollständig. Einfache Anführungszeichen können erforderlich sein, um zu verhindern, dass die Shell sie auflöst.
Beispielsweise:

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

--ignore-fn=
Jede direkte Heap-Zuweisung (dh ein Aufruf an malloc, neu, usw. oder ein Aufruf einer Funktion
benannt nach an --alloc-fn Option), die in einer durch diese Option angegebenen Funktion auftritt, wird
ignoriert werden. Dies ist vor allem für Testzwecke nützlich. Diese Option kann angegeben werden
mehrmals in der Befehlszeile, um mehrere Funktionen zu benennen.

Jedes Realloc eines ignorierten Blocks wird ebenfalls ignoriert, auch wenn die Realloc Anruf tut
in einer ignorierten Funktion nicht vorkommen. Dies vermeidet die Möglichkeit negativer Heap-Größen
wenn ignorierte Blöcke mit verkleinert werden Realloc.

Die Regeln für das Schreiben von C++-Funktionsnamen sind die gleichen wie für --alloc-fn zu teilen.

--threshold= [Ursprünglich: 1.0]
Der Signifikanzschwellenwert für Heap-Zuordnungen als Prozentsatz der Gesamtspeichergröße.
Zuordnungsbaumeinträge, die weniger ausmachen, werden aggregiert. Beachten Sie, dass
dies sollte zusammen mit der gleichnamigen Option von ms_print angegeben werden.

--peak-inaccuracy= [Ursprünglich: 1.0]
Massif zeichnet nicht unbedingt die tatsächliche globale Speicherzuweisungsspitze auf; von
Standardmäßig zeichnet es nur dann einen Peak auf, wenn die globale Speicherzuweisungsgröße den
vorherigen Höchststand um mindestens 1.0 %. Dies liegt daran, dass es viele lokale Zuordnungen geben kann
Gipfel auf dem Weg, und einen detaillierten Schnappschuss für jeden einzelnen zu machen, wäre teuer
und verschwenderisch, da alle bis auf einen später verworfen werden. Diese Ungenauigkeit kann sein
geändert (sogar auf 0.0%) über diese Option, aber Massif läuft drastisch langsamer als die
Zahl geht gegen Null.

--Zeiteinheit= [Ursprünglich: i]
Die für die Profilerstellung verwendete Zeiteinheit. Es gibt drei Möglichkeiten: Anweisungen
ausgeführt (i), was in den meisten Fällen gut ist; echte (Wanduhr) Zeit (ms, dh
Millisekunden), was manchmal nützlich ist; und Bytes auf dem Heap zugewiesen/freigegeben
und/oder Stack (B), was für sehr kurzfristige Programme und zum Testen nützlich ist
Zwecke, da es auf verschiedenen Maschinen am besten reproduzierbar ist.

--detailed-freq= [Ursprünglich: 10]
Häufigkeit detaillierter Schnappschüsse. Mit --detaillierte-freq=1, jeder Schnappschuss ist detailliert.

--max-snapshots= [Ursprünglich: 100]
Die maximale Anzahl aufgezeichneter Schnappschüsse. Bei Einstellung auf N für alle Programme außer sehr
kurzlaufenden, wird die endgültige Anzahl von Snapshots zwischen N/2 und N liegen.

--massif-out-file= [Ursprünglich: massiv.out.%p]
Schreiben Sie die Profildaten in eine Datei und nicht in die Standardausgabedatei.
massiv.aus. . Die %p und %q Formatbezeichner können verwendet werden, um die Prozess-ID einzubetten
und/oder den Inhalt einer Umgebungsvariablen im Namen, wie es bei der
Kernoption --Logdatei.

SGCHECK OPTIONAL

Derzeit gibt es keine SGCheck-spezifischen Befehlszeilenoptionen.

BBV OPTIONAL

--bb-out-file= [Ursprünglich: bb.out.%p]
Diese Option wählt den Namen der Basisblockvektordatei aus. Die %p und %q Format
Spezifizierer können verwendet werden, um die Prozess-ID und/oder den Inhalt einer Umgebung einzubetten
variabel im Namen, wie bei der Option core --Logdatei.

--pc-out-file= [Ursprünglich: PC.out.%p]
Diese Option wählt den Namen der PC-Datei aus. Diese Datei enthält Programmzähleradressen
und Funktionsnameninfo für die verschiedenen Basisblöcke. Dies kann in Verbindung verwendet werden
mit der grundlegenden Blockvektordatei zum schnellen Vorspulen über Funktionsnamen statt nur
Anweisung zählt. Die %p und %q Formatbezeichner können verwendet werden, um den Prozess einzubetten
ID und/oder der Inhalt einer Umgebungsvariablen im Namen, wie bei der
Kernoption --Logdatei.

--interval-size= [Ursprünglich: 100000000]
Diese Option wählt die Größe des zu verwendenden Intervalls aus. Der Standardwert ist 100 Millionen
Anweisungen, was ein häufig verwendeter Wert ist. Andere Größen können verwendet werden; kleiner
Intervalle können Programmen mit feinkörnigeren Phasen helfen. Jedoch kleinere Intervallgröße
kann aufgrund von Aufwärmeffekten zu Genauigkeitsproblemen führen (beim schnellen Vorlauf der verschiedenen
Architekturmerkmale werden nicht initialisiert, und es dauert einige Zeit
Anweisungen, bevor sie sich auf den Zustand "aufwärmen", ohne den eine vollständige Simulation wäre
der schnelle Vorlauf. Große Intervallgrößen neigen dazu, dies zu mildern.)

--instr-count-only [Ursprünglich: Nein]
Diese Option weist das Tool an, nur die Gesamtzahl der Anweisungen anzuzeigen und nicht
Generieren Sie die eigentliche grundlegende Blockvektordatei. Dies ist nützlich zum Debuggen und für
Sammeln von Befehlszählinformationen, ohne den großen Basisblockvektor zu erzeugen
Dateien.

LAKAI OPTIONAL

--basic-counts= [Ursprünglich: Jawohl]
Wenn aktiviert, druckt Lackey die folgenden Statistiken und Informationen über die
Ausführung des Client-Programms:

1. Die Anzahl der Aufrufe der Funktion, die durch die --fnname Option (die Standardeinstellung)
ist Hauptsache). Wenn die Symbole des Programms entfernt wurden, wird immer gezählt
Null.

2. Die Anzahl der angetroffenen bedingten Verzweigungen und die Anzahl und der Anteil der
die genommen.

3. Die Anzahl der vom Programm eingegebenen und abgeschlossenen Superblöcke. Beachten Sie, dass aufgrund von
Optimierungen durch das JIT, ist dies kein genauer Wert.

4. Die Anzahl der Gastanweisungen (x86, amd64, ppc usw.) und IR-Anweisungen
hingerichtet. IR ist Valgrinds RISC-ähnliche Zwischendarstellung, über die alle
Instrumentierung erfolgt.

5. Verhältnisse zwischen einigen dieser Zählungen.

6. Der Exit-Code des Client-Programms.

--detailed-counts= [Ursprünglich: Nein]
Wenn aktiviert, druckt Lackey eine Tabelle mit den Anzahlen von Ladungen, Speichern und ALU
Operationen, differenziert nach ihren IR-Typen. Die IR-Typen werden durch ihre IR . identifiziert
Namen ("I1", "I8", ... "I128", "F32", "F64" und "V128").

--trace-mem= [Ursprünglich: Nein]
Wenn aktiviert, druckt Lackey die Größe und Adresse fast jedes Speicherzugriffs von
das Programm. Weitere Informationen finden Sie in den Kommentaren oben in der Datei lackey/lk_main.c
über das Ausgabeformat, seine Funktionsweise und Ungenauigkeiten im Adress-Trace. Notiz
dass diese Option immense Mengen an Output produziert.

--trace-superblocks= [Ursprünglich: Nein]
Wenn aktiviert, druckt Lackey die Adresse jedes Superblocks aus (ein einzelner Eintrag,
mehrfacher Exit, linearer Codeblock), der vom Programm ausgeführt wird. Dies ist in erster Linie von
Interesse an Valgrind-Entwicklern. Siehe die Kommentare oben in der Datei
lackey/lk_main.c für Details zum Ausgabeformat. Beachten Sie, dass diese Option erzeugt
große Ausgabemengen.

--fnname= [Ursprünglich: hauptsächlich]
Ändert die Funktion, für die Anrufe gezählt werden, wenn --basic-counts=ja angegeben.

Nutzen Sie Valgrind online mit den onworks.net-Diensten