Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] ptrace - Suivre un processus. [size=18] [b]Résumé[/b] [/size] [b]#include <sys/ptrace.h>[/b] [b][i]long ptrace(enum __ptrace_request requête , int pid , void * addr , int data );[/i][/b] [size=18] [b]Description[/b] [/size] L'appel-système [b]ptrace[/b] fournit au processus parent un moyen de contrôler l'exécution d'un autre processus et d'éditer son image mémoire. L'utilisation primordiale de cette fonction est l'implémentation de points d'arrêt pour le débugging.     Le père peut démarrer un suivi en appelant [b]fork (2)[/b] et que le fils créé face un PTRACE_TRACEME, suivi (en général) par un [b]exec (3).[/b] Autrement, le père peut commencer un suivi sur un processus existant en utilisant PTRACE_ATTACH.     Le processus fils suivi s'arrêtera à chaque fois qu'un signal lui sera délivré, même si le signal est ignoré (à l'exception de SIGKILL qui a les effets habituels). Le père sera prévenu à son prochain [b]wait (2)[/b] et pourra inspecter et modifier le processus fils pendant son arrêt. Le parent peut également faire continuer l'exécution de son fils, éventuellement en ignorant le signal ayant déclenché l'arrêt, ou envoyant un autre signal.     Quand le père a fini le suivi, il peut terminer le fils avec PTRACE_KILL ou le faire continuer normalement, non suivi, avec PTRACE_DETACH.     La valeur de l'argument [i]requête[/i] indique précisément l'action à entreprendre. [table][row][col]    [/col][col]PTRACE_TRACEME Le processus en cours va être suivi par son père. Le parent doit être en attente de suivi du fils. Tout signal (sauf SIGKILL) reçu par le processus l'arrêtera, et le père sera notifié grâce à [b]wait .[/b] De plus, les appels-ultérieurs à [b]exec[/b] par ce processus lui enverront SIGTRAP, ce qui donne au père la possibilité de reprendre le contrôle avant que le nouveau programme continue son exécution? Un processus ne doit pas envoyer cette requête si son père n'est pas prêt à le suivre. Dans cette requête ([i]pid[/i], [i]addr[/i], et [i]data[/i] sont ignorés.)[/col][/row][/table]     La requête ci-dessus ne sert que dans le processus fils. Les autres ne servent que dans le père. Par la suite, [i]pid[/i] précise le fils sur lequel agir. Pour les requêtes autres que PTRACE_KILL, le fils doit être arrêté. [table][row][col]    [/col][col]PTRACE_PEEKTEXT, PTRACE_PEEKDATA Lire un mot à l'adresse [b]addr [/b] dans l'espace mémoire du fils et renvoyer la valeur en résultat de [b]ptrace .[/b] Linux ne sépare pas les espaces d'adressage de code et de données, ainsi ces deux requêtes sont équivalentes. ([i]data[/i] est ignoré).[/col][/row][/table] [table][row][col]    [/col][col]PTRACE_PEEKUSR Lire un mot à l'adresse [i]addr[/i] dans l'espace [b]USER[/b] du fils, qui contient les registres et diverses informations sur le processus (voir <linux/user.h> et <sys/user.h>). La valeur est renvoyé en résultat de [b]ptrace .[/b] En principe, l'adresse doit être alignée sur une frontière de mots, bien que cela varie selon les architectures ([i]data[/i] est ignoré).[/col][/row][/table] [table][row][col]    [/col][col]PTRACE_POKETEXT, PTRACE_POKEDATA Copier un mot depuis l'adresse [b]data[/b] de la mémoire du père vers l'adresse [b]addr[/b] de la mémoire du fils. Comme précédemment, les deux requêtes sont équivalentes.[/col][/row][/table] [table][row][col]    [/col][col]PTRACE_POKEUSR Copier un mot depuis l'emplacement [b]data[/b] de la mémoire du père vers l'emplacement [i]addr[/i] dans l'espace [b]USER[/b] du processus fils. Comme plus haut, les emplacements doivent être alignés sur une frontière de mot. Pour maintenir l'intégrité du noyau, certaines modifications de la zone [b]USER[/b] sont interdites.[/col][/row][/table] [table][row][col]    [/col][col]PTRACE_GETREGS, PTRACE_GETFPREGS Copier les registres généraux ou du processeur en virgule flottante, vers l'adresse [i]data[/i] du père. Voir <linux/user.h> pour les détails sur le format des données ([i]addr[/i] est ignoré).[/col][/row][/table] [table][row][col]    [/col][col]PTRACE_SETREGS, PTRACE_SETFPREGS Remplir les registres généraux ou du processeur en virgule flottante, depuis le contenu de l'adresse [i]data[/i] du père. Comme pour PTRACE_POKEUSR certaines modifications sont interdites. ([i]addr[/i] est ignoré).[/col][/row][/table] [table][row][col]    [/col][col]PTRACE_CONT Redémarrer le processus fils arrêté. Si [i]data[/i] est non-nul et autre que SIGSTOP, il est interprété comme un numéro de signal à délivrer au fils ; sinon aucun signal n'est délivré. On peut ainsi contrôler si un signal envoyé au fils doit lui être délivré ou non ([i]addr[/i] est ignoré).[/col][/row][/table] [table][row][col]    [/col][col]PTRACE_SYSCALL, PTRACE_SINGLESTEP Redémarrer le processus fils arrêté comme pour PTRACE_CONT, mais en s'arrangeant pour qu'il soit arrêté à la prochaine entrée ou sortie d'un appel-système, ou après la prochaine instruction, respectivement. (Le fils sera aussi arrêté par l'arrivée d'un signal). Du point de vue du père, le fils semblera être arrêté par SIGTRAP. Ainsi, pour PTRACE_SYSCALL l'idée est d'inspecter les arguments de l'appel-système au premier arrêt puis de faire un autre PTRACE_SYSCALL et d'inspecter la valeur de retour au second arrêt. ([i]add[/i] est ignoré).[/col][/row][/table] [table][row][col]    [/col][col]PTRACE_KILL Envoyer au fils un signal [b]SIGKILL[/b] pour le terminer. ([i]addr[/i] et [i]data[/i] sont ignorés).[/col][/row][/table] [table][row][col]    [/col][col]PTRACE_ATTACH Attacher le processus numéro [b]pid ,[/b] pour le suivre. Le comportement du fils est le même que s'il avait fait un PTRACE_TRACEME. Le processus appelant devient alors le père pour de nombreuses choses (il recevra les notifications d'évènements, et sera indiqué comme le père dans un [b]ps (1)).[/b] Mais [b]getppid (2)[/b] renverra dans le fils le PID du vrai père. Le processus fils va recevoir un SIGSTOP, mais il ne sera peut-être pas stoppé tout de suite, utilisez [b]wait[/b] pour attendre son arrêt ([i]addr[/i] et [i]data[/i] sont ignorés).[/col][/row][/table] [table][row][col]    [/col][col]PTRACE_DETACH Relancer un processus fils comme avec PTRACE_CONT, en commençant pas le détacher, ce qui rétablit sa parenté originale. Le processus ne sera plus suivi. Bien que cela soit involontaire, sous Linux un processus suivi peut être être détaché ainsi quelque soit la méthode employée pour démarrer le suivi. ([i]addr[/i] est ignoré).[/col][/row][/table] [size=18] [b]Notes[/b] [/size] Bien que les arguments de [b]ptrace[/b] soient interprétés comme dans le prototype plus haut, la bibliothèque GlibC déclare [b]ptrace[/b] comme une fonction variadique où seul l'argument [i]request[/i] est fixé. Ceci signifie que que les arguments finaux inutiles peuvent être omis, bien que cela utilise un comportement non documenté de [b]gcc (1).[/b]     [b]init (8),[/b] le processus numéro 1, ne peut pas être suivi.     La disposition du contenu de la mémoire et de la zone USER dépendent du système d'exploitation et de l'architecture.     La taille d'un mot, "word" est déterminée par la version du système d'exploitation (par exemple 32 bits pour Linux-32-bits, etc.)     Le suivi peut engendrer des modifications subtiles dans le fonctionnement du processus. Par exemple si un processus est attaché avec PTRACE_ATTACH, son père original ne peut plus recevoir les notifications avec [b]wait[/b] lorsqu'il s'arrête, et il n'y a pas de moyen de simuler cette notification.     Cette page documente le fonctionnement actuel de [b]ptrace[/b] sous Linux. Celui-ci peut varier sensiblement sur d'autres types d'Unix. De toute façon, l'utilisation de [b]ptrace[/b] dépend fortement de l'architecture et du système d'exploitation.     La page de manuel de SunOS décrit [b]ptrace[/b] comme un appel-système "unique and arcane", ce qu'il est. Le mécanisme de débogage basé sur le système proc, présent dans Solaris 2 implémente un sur-ensemble des fonctionnalités de [b]ptrace[/b] de manière plus puissante et plus uniforme. [size=18] [b]Valeur renvoyée[/b] [/size] Pour les requêtes PTRACE_PEEK, [b]ptrace[/b] renvoie la valeur réclamée et zéro pour les autres requêtes, ou -1 en cas d'échec en remplissant [i]errno[/i] avec le code d'erreur. Comme la valeur renvoyée par une requête PTRACE_PEEK peut légitimement être -1, il faut vérifier [i]errno[/i] après un tel appel pour vérifier si une erreur s'est produite. [size=18] [b]Erreurs[/b] [/size] [b]EPERM[/b] [table][row][col]    [/col][col]Le processus indiqué ne peut pas être suivi. Cela peut être dû à un manque de privilège du parent. Les processus non-root ne peuvent pas suivre les processus auxquels ils ne peuvent envoyer de signal, ou ceux qui s'exécutent Set-UID/Set-GID. En outre, le processus visé peut être déjà suivi, ou être [b]init[/b] (pid 1).[/col][/row][/table] [b]ESRCH[/b] [table][row][col]    [/col][col]Le processus indiqué n'existe pas, ou n'est pas suivi par l'appelant, ou n'est pas arrêté (pour les requêtes qui en ont besoin).[/col][/row][/table] [b]EIO[/b] [table][row][col]    [/col][col]La [i]requête[/i] n'est pas valide ou une tentative de lecture ou d'écriture dans une zone invalide de mémoire a eu lieu. Il peut également y avoir un problème d'alignement sur une frontière de mot, ou une tentative de redémarrage en envoyant un signal invalide.[/col][/row][/table] [b]EFAULT[/b] [table][row][col]    [/col][col]Tentative de lire ou écrire dans une zone mémoire invalide du processus ou du père. Malheureusement sous Linux, certaines variantes de cette erreur déclencheront EIO ou EFAULT plus ou moins arbitrairement.[/col][/row][/table] [size=18] [b]Conformité[/b] [/size] SVr4, SVID EXT, AT&T, X/OPEN, BSD 4.3 [size=18] [b]Voir aussi[/b] [/size] [b]gdb (1),[/b] [b]strace (1),[/b] [b]execve (2),[/b] [b]fork (2),[/b] [b]signal (2),[/b] [b]wait (2)[/b] [b]exec (3)[/b] [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 1996-2003.
Fichier