Dies ist der Befehl perf-probe, der beim kostenlosen Hosting-Anbieter OnWorks mit einer unserer zahlreichen kostenlosen Online-Workstations wie Ubuntu Online, Fedora Online, dem Windows-Online-Emulator oder dem MAC OS-Online-Emulator ausgeführt werden kann
PROGRAMM:
NAME/FUNKTION
perf-probe – Definieren Sie neue dynamische Tracepoints
ZUSAMMENFASSUNG
perf Sonde [Optionen] --add=SONDE [...]
or
perf Sonde [Optionen] PROBE
or
perf Sonde [Optionen] --del=[GRUPPE:]EREIGNIS [...]
or
perf Sonde --list[=[GROUP:]EVENT]
or
perf Sonde [Optionen] --line=LINE
or
perf Sonde [Optionen] --vars=PROBEPOINT
or
perf Sonde [Optionen] --funcs
BESCHREIBUNG
Dieser Befehl definiert dynamische Tracepoint-Ereignisse nach Symbol und Registern ohne Debuginfo.
oder durch C-Ausdrücke (C-Zeilennummern, C-Funktionsnamen und C-lokale Variablen) mit
Debug-Informationen.
OPTIONAL
-k, --vmlinux=PFAD
Geben Sie den vmlinux-Pfad an, der debuginfo (Zwerg-Binärdatei) enthält.
-m, --module=MODNAME|PFAD
Geben Sie den Modulnamen an, in dem perf-probe nach Sondenpunkten oder -linien sucht. Wenn ein Pfad von
Wenn die Moduldatei übergeben wird, behandelt Perf-Probe sie als Offline-Modul (das bedeutet, dass Sie dies tun können).
Hinzufügen einer Sonde zu einem Modul, das noch nicht geladen wurde).
-s, --source=PFAD
Geben Sie den Pfad zur Kernelquelle an.
-v, --verbose
Seien Sie ausführlicher (geparste Argumente anzeigen usw.). Kann nicht mit -q verwendet werden.
-q, --leise
Seien Sie ruhig (zeigen Sie keine Meldungen einschließlich Fehler an). Kann nicht mit -v verwendet werden.
-a, --add=
Definieren Sie ein Sondenereignis (Einzelheiten finden Sie unter PROBE SYNTAX).
-d, --del=
Probe-Ereignisse löschen. Dies akzeptiert globale Platzhalter(*, ?) und Zeichenklassen (z. B
[az], [!AZ]).
-l, --list[=[GROUP:]EVENT]
Aktuelle Sondenereignisse auflisten. Dies kann auch Filtermuster von Ereignisnamen akzeptieren.
-L, --line=
Zeigt Quellcodezeilen an, die untersucht werden können. Dies erfordert ein Argument, das a angibt
Bereich des Quellcodes. (Einzelheiten finden Sie unter ZEILENSYNTAX.)
-V, --vars=
Zeigt verfügbare lokale Variablen an einem bestimmten Sondenpunkt an. Die Argumentsyntax ist dieselbe wie
PROBE-SYNTAX, aber KEINE ARGs.
--externs
(Nur für --vars) Zeigt zusätzlich zu lokalen Variablen auch externe definierte Variablen an.
--no-inlines
(Nur für --add) Suche nur nach nicht inline-Funktionen. Die Funktionen, die dies nicht tun
have-Instanzen werden ignoriert.
-F, --funcs[=FILTER]
Verfügbare Funktionen in einem bestimmten Modul oder Kernel anzeigen. Mit -x/--exec kann auch eine Liste erstellt werden
Funktionen in einer ausführbaren Datei / gemeinsam genutzten Bibliothek im Benutzerbereich. Dies kann auch einen FILTER akzeptieren
Regelargument.
--filter=FILTER
(Nur für --vars und --funcs) Filter festlegen. FILTER ist eine Kombination aus Glob-Mustern, siehe
FILTERMUSTER für Details. Der Standardfilter ist „!k???tab_* & !crc_*" für --vars und
„!_*“ für --funcs. Bei Angabe mehrerer Filter wird nur der letzte Filter verwendet.
-f, --force
Erzwingen Sie das Hinzufügen von Ereignissen mit vorhandenem Namen.
-n, --Trockenlauf
Probelauf. Mit dieser Option führen --add und --del kein tatsächliches Hinzufügen und Entfernen aus
Operationen.
--max-probes=NUM
Legen Sie die maximale Anzahl von Prüfpunkten für ein Ereignis fest. Der Standardwert ist 128.
-x, --exec=PFAD
Geben Sie den Pfad zur ausführbaren Datei oder gemeinsam genutzten Bibliotheksdatei für die Benutzerbereichsverfolgung an. Kann auch
kann mit der Option --funcs verwendet werden.
--demangle
Anwendungssymbole entschlüsseln. --no-demangle steht auch zum Deaktivieren zur Verfügung
entwirren.
--demangle-kernel
Kernelsymbole entzerren. --no-demangle-kernel ist auch zum Deaktivieren des Kernels verfügbar
entwirren.
Wenn keine -m/-x-Optionen vorhanden sind, prüft der Perf-Probe, ob das erste Argument nach den Optionen lautet
ein absoluter Pfadname. Wenn es sich um einen absoluten Pfad handelt, verwendet Perf Probe ihn als Ziel
Zu prüfende Modul-/Ziel-User-Space-Binärdatei.
SONDE SYNTAX
Sondenpunkte werden durch die folgende Syntax definiert.
1) Definieren Sie ein Ereignis basierend auf dem Funktionsnamen
[EVENT=]FUNC[@SRC][:RLN|+OFFS|%return|;PTN] [ARG ...]
2) Definieren Sie das Ereignis basierend auf der Quelldatei mit der Zeilennummer
[EVENT=]SRC:ALN [ARG ...]
3) Definieren Sie ein Ereignis basierend auf der Quelldatei mit Lazy-Muster
[EVENT=]SRC;PTN [ARG ...]
EVENT Gibt den Namen des neuen Ereignisses an. Wenn es weggelassen wird, wird der Name des untersuchten Ereignisses festgelegt
Funktion. Derzeit ist der Name der Ereignisgruppe auf festgelegt Sonde. FUNK Gibt eine geprüfte Funktion an
Name, und es kann eine der folgenden Optionen haben; +OFFS ist der Offset von der Funktion
Eintragsadresse in Bytes, :RLN ist die relative Zeilennummer aus der Funktionseingabezeile und
%zurückkehren bedeutet, dass die Funktionsrückgabe geprüft wird. Und ;PTN bedeutet Lazy-Matching-Muster (siehe
LAZY MATCHING). Beachten Sie, dass ;PTN muss das Ende der Sondenpunktdefinition sein. Zusätzlich,
@SRC Gibt eine Quelldatei an, die diese Funktion hat. Es ist auch möglich, a anzugeben
Sondenpunkt anhand der Quellzeilennummer oder Lazy Matching mithilfe von SRC:ALN or SRC;PTN Syntax,
woher SRC ist der Quelldateipfad, :ALN ist die Zeilennummer und ;PTN ist das Lazy Matching
Muster. ARG Gibt die Argumente dieses Prüfpunkts an (siehe PROBE ARGUMENT).
SONDE ARGUMENT
Jedes Sondenargument folgt der folgenden Syntax.
[NAME=]LOCALVAR|$retval|%REG|@SYMBOL[:TYPE]
NAME/FUNKTION Gibt den Namen dieses Arguments an (optional). Sie können den Namen local verwenden
Variable, lokales Datenstrukturelement (z. B. var→field, var.field2), lokales Array mit festem
Index (z. B. Array[1], Var→Array[0], Var→Zeiger[2]) oder kprobe-tracer-Argumentformat
(z. B. $retval, %ax usw.). Beachten Sie, dass der Name dieses Arguments als letztes festgelegt wird
Mitgliedsname, wenn Sie ein lokales Datenstrukturmitglied angeben (z. B. Feld2 für
var→field1.field2.) $vars und $params Spezielle Argumente stehen auch für NAME zur Verfügung. $vars
wird um die lokalen Variablen (einschließlich Funktionsparameter) erweitert, auf die unter zugegriffen werden kann
gegebener Sondenpunkt. $params wird nur auf die Funktionsparameter erweitert. TYP wirft die
Typ dieses Arguments (optional). Wenn es weggelassen wird, legt das Perf-Probe den Typ automatisch fest
auf debuginfo. Sie können angeben Schnur Typ nur für die lokale Variable oder das Strukturmitglied
Das ist ein Array von oder ein Zeiger auf verkohlen or ohne Vorzeichen verkohlen Art.
Auf x86-Systemen ist %REG immer die Kurzform des Registers: zum Beispiel %AX. %RAX oder
%EAX ist ungültig.
LINE SYNTAX
Der Zeilenbereich wird durch die folgende Syntax beschrieben.
„FUNC[@SRC][:RLN[+NUM|-RLN2]]|SRC[:ALN[+NUM|-ALN2]]“
FUNC gibt den Funktionsnamen zum Anzeigen von Linien an. RLN ist die Startliniennummer von
Funktionseingabezeile und RLN2 ist die Endzeilennummer. Genauso wie die Sondensyntax: SRC Mittel verbinden
der Quelldateipfad, ALN ist die Startzeilennummer und ALN2 ist die Endzeilennummer in der Datei.
Es ist auch möglich, mithilfe von festzulegen, wie viele Zeilen angezeigt werden sollen NUM. Außerdem FUNC@SRC
Die Kombination eignet sich gut für die Suche nach einer bestimmten Funktion, wenn mehrere Funktionen dieselbe Funktion haben
Name. „source.c:100-120“ zeigt also Zeilen zwischen dem 100. und dem 20. Platz in der Datei „source.c“ an. Und
„func:10+20“ zeigt 20 Zeilen ab der 10. Zeile der Funktion func.
FAUL PASSEND
Der Lazy-Line-Matching ähnelt dem Glob-Matching, ignoriert jedoch Leerzeichen sowohl im Muster als auch im Ziel. Dies akzeptiert also Platzhalter ('*', '?') und Zeichenklassen (z. B. [az], [!AZ]).
z.B a=* kann Streichhölzer a = b, a = b, a == b und so weiter.
Dies bietet eine gewisse Flexibilität und Robustheit für die Prüfung von Punktdefinitionen
kleinere Codeänderungen. Beispielsweise kann die tatsächliche 10. Zeile von Schedule() einfach um verschoben werden
Schedule() ändern, aber die gleiche Zeilenübereinstimmung rq=cpu_rq* kann noch in der vorhanden sein
Funktion.)
FILTER MUSTER
Das Filtermuster ist ein globales Matching-Muster zum Filtern von Variablen.
Darüber hinaus können Sie „!“ verwenden. zum Festlegen der Filterregel. Sie können auch mehrere Regeln mit „&“ oder „|“ kombinieren und diese Regeln mit „(“ „) zu einer Regel zusammenfassen.
Beispielsweise zeigt perf probe -V mit --filter "foo* | bar*" Variablen an, die mit "foo" oder beginnen
"Bar". Mit --filter „!foo* & *bar“ zeigt perf probe -V Variablen an, die nicht mit beginnen
„foo“ und enden mit „bar“, wie „fizzbar“. Aber „foobar“ wird herausgefiltert.
Beispiele:
Zeigt an, welche Zeilen in Schedule() geprüft werden können:
./perf Probe --line Zeitplan
Fügen Sie einen Prüfpunkt in der 12. Zeile der Funktion „schedule()“ mit der Aufzeichnung der lokalen CPU-Variablen hinzu:
./perf Probe-Zeitplan: 12 CPU
or
./perf probe --add='schedule:12 cpu'
Dadurch werden eine oder mehrere Sonden hinzugefügt, deren Name mit „schedule“ beginnt.
Fügen Sie Sonden zu Zeilen in der Funktion „schedule()“ hinzu, die update_rq_clock() aufruft.
./perf Probe 'schedule;update_rq_clock*'
or
./perf probe --add='schedule;update_rq_clock*'
Alle Sonden nach Schedule() löschen.
./perf probe --del='schedule*'
Fügen Sie Sonden zur zfree()-Funktion in /bin/zsh hinzu
./perf probe -x /bin/zsh zfree oder ./perf probe /bin/zsh zfree
Fügen Sie Sonden zur malloc()-Funktion in libc hinzu
./perf probe -x /lib/libc.so.6 malloc oder ./perf probe /lib/libc.so.6 malloc
Nutzen Sie perf-probe online über die Dienste von onworks.net