Kapitel 30 Der Provider pid

Der Provider pid ermöglicht die Ablaufverfolgung des Eintritts einer beliebigen Funktion in einem Benutzerprozess und deren Rückkehr sowie jeder mit einer absoluten Adresse oder einem Funktionsversatz angegebenen Anweisung. Wenn die Prüfpunkte nicht aktiviert sind, verursacht der Provider pid keine Prüftätigkeit. Aktivierte Prüfpunkte bewirken lediglich auf den überwachten Prozessen eine Prüftätigkeit.

Wenn der Compiler eine Funktion als Inline festlegt, wird der Prüfpunkt des Providers pid nicht ausgelöst. Lesen Sie in der Dokumentation Ihres Compilers nach, um das Festlegen einer Funktion als Inline zur Compilierungszeit zu vermeiden.

Das Verhalten des Providers pid kann unvorhersehbar sein, wenn er in einer Funktion, die Unterfunktionen mithilfe von Funktionszeigern aufruft, Prüfpunkte besitzt. Sie können Prüfpunkte explizit an den Adressen des·Einsprung- und Austrittspunktes einer Funktion setzen, wenn Sie solche Funktionen analysieren wollen.

Benennung von pid-Prüfpunkten

Eigentlich definiert der Provider pid eine Klasse von Providern. Theoretisch kann jeder Prozess einen eigenen pid-Provider besitzen. So würden wir beispielsweise für die Ablaufverfolgung eines Prozesses mit der ID 123 den Provider pid123 verwenden. Bei Prüfpunkten eines dieser Provider bezieht sich der Modulteil der Prüfpunktbeschreibung auf ein in dem Adressraum des entsprechenden Prozesses geladenes Objekt. Im folgenden Beispiel wird mithilfe von mdb(1) eine Liste der Objekte angezeigt:

$ mdb -p 1234
Loading modules: [ ld.so.1 libc.so.1 ]
> ::objects
    BASE    LIMIT     SIZE NAME
   10000    34000    24000 /usr/bin/csh
ff3c0000 ff3e8000    28000 /lib/ld.so.1
ff350000 ff37a000    2a000 /lib/libcurses.so.1
ff200000 ff2be000    be000 /lib/libc.so.1
ff3a0000 ff3a2000     2000 /lib/libdl.so.1
ff320000 ff324000     4000 /platform/sun4u/lib/libc_psr.so.1

In der Prüfpunktbeschreibung geben Sie das Objekt nicht mit dem vollständigen Pfadnamen, sondern mit dem Dateinamen an. Außerdem können Sie das Suffix „.1“ oder „so.1“ auslassen. Alle nachfolgenden Beispiele benennen denselben Prüfpunkt:

pid123:libc.so.1:strcpy:entry
pid123:libc.so:strcpy:entry
pid123:libc:strcpy:entry

Das erste Beispiel stellt den tatsächlichen Namen des Prüfpunkts dar. Die anderen Beispiele sind praktische Aliasnamen, die intern durch den vollständigen Ladeobjektnamen ersetzt werden.

Für das Ladeobjekt der ausführbaren Datei kann der Aliasname a.out verwendet werden . Die folgenden beiden Prüfpunktbeschreibungen benennen denselben Prüfpunkt:

pid123:csh:main:return
pid123:a.out:main:return

Wie bei allen verankerten DTrace-Prüfpunkten gibt auch hier das Funktionsfeld der Prüfpunktbeschreibung eine Funktion im Modulfeld an. Es ist denkbar, dass im Binärcode einer Benutzeranwendung mehrere Namen für dieselbe Funktion vorhanden sind. So könnte beispielsweise mutex_lock ein alternativer Name für die Funktion pthread_mutex_lock in libc.so.1 sein . DTrace wählt für derartige Funktionen einen kanonischen Namen und verwendet diesen intern. Das folgende Beispiel zeigt, wie DTrace Modul- und Funktionsnamen intern einer kanonischen Form neu zuordnet:

# dtrace -q -n pid101267:libc:mutex_lock:entry'{ \
    printf("%s:%s:%s:%s\n", probeprov, probemod, probefunc, probename); }'
pid101267:libc.so.1:pthread_mutex_lock:entry
^C

Diese automatische Umbenennung bedeutet, dass sich die Namen der von Ihnen aktivierten Prüfpunkte leicht von den tatsächlich aktivierten unterscheiden können. Dabei wird bei jeder Ausführung von DTrace auf Systemen mit derselben Solaris-Version derselbe kanonische Name gewählt.

Beispiele zur effektiven Verwendung des Providers pid finden Sie in Kapitel 33Ablaufverfolgung von Benutzerprozessen.

Prüfpunkte für Funktionsgrenzen

Analog zu dem FBT-Provider, der die Ablaufverfolgung von Funktionseintritten und der Rückkehr von Funktionen im Kernel ermöglicht, bietet der Provider pid diese Fähigkeit für Benutzerprogramme. Die meisten in diesem Handbuch angeführten Beispiele für die Ablaufverfolgung von Kernel-Funktionsaufrufen mit dem FBT-Provider lassen sich in leicht abgeänderter Form auf Benutzerprozesse übertragen.

entry-Prüfpunkte

Ein entry-Prüfpunkt wird bei Aufruf der überwachten Funktion ausgelöst. Die Argumente für entry-Prüfpunkte sind die Werte der Argumente der überwachten Funktion.

return-Prüfpunkte

return-Prüfpunkte werden bei der Rückkehr von der verfolgten Funktion ausgelöst, oder wenn diese mit dem Aufruf einer anderen Funktion endet. Der Wert von arg0 ist der Versatz der Rückgabeanweisung in der Funktion; arg1 enthält den Rückgabewert.

argN gibt ungefilterte Rohwerte vom Datentyp int64_t zurück. Der Provider pid unterstützt das Format args[N ] nicht.

Prüfpunkte für den Funktionsversatz

Der Provider pid ermöglicht die Ablaufverfolgung beliebiger Anweisungen in einer Funktion. Um beispielsweise die Anweisung an 4 Byte in einer Funktion namens main() zu überwachen, könnten Sie einen ähnlichen Befehl wie diesen verwenden:

pid123:a.out:main:4

Jedes Mal, wenn das Programm die Anweisung an der Adresse main+4 ausführt, wird dieser Prüfpunkt aktiviert. Die Argumente für Versatz-Prüfpunkte sind nicht definiert. Mit dem Vektor uregs[] lässt sich der Prozessstatus an diesen Prüfpunktstellen untersuchen. Weitere Informationen finden Sie unter Der Vektor uregs[].

Stabilität

Der Provider pid beschreibt die verschiedenen Stabilitäten anhand des DTrace-Stabilitätsmechanismus gemäß der folgenden Tabelle. Weitere Informationen zum Stabilitätsmechanismus finden Sie in Kapitel 39Stabilität.