API du Debugger

L'interface du Debugger

SpiderMonkey, le moteur JavaScript de Mozilla fournit une interface de débogage appelée Debugger. Cette interface permet à du code JavaScript d'observer et de manipuler l'exécution de code JavaScript. Les outils de développement de Firefox et le module complémentaire Firefbug utilisent Debugger pour implémenter leurs débogueurs JavaScript. Cependant, Debugger est très générale, et peut être utilisée pour implémenter d'autres sortes d'outils, par exemple des traceurs ou des analyseurs de protection.

Debugger a trois avantages principaux :

  • C'est une interface source level : Elle fonctionne en terme de langage JavaScript et non en langage machine. Elle fonctionne avec des objets JavaScript, des stack frames, des environnement, code, etc. Et présente une interface constante peut importe si le code débogué est interprété, compilé ou optimisé. Avoir une bonne maitrise du JavaScript est tout ce qui est requis pour utiliser Debugger avec succès. Il n'est même pas nécessaire d'être familier avec l'implémentation du langage.

  • Elle s'utilise avec du code JavaScript. Le JavaScript est à la fois le langage déboguer et le langage de l'implémentation de l'outil. Ainsi, les qualités qui font de JavaScript un langage efficace sur le web peuvent être importées dans les outils pour développeurs. Comme on s'y attend de la part d'une API JavaScript, Debugger est une interface sûre : utiliser (ou mal utiliser) Debugger ne devrait jamais faire crasher Gecko. Les erreurs lèvent proprement des exceptions JavaScript.

  • C'est une API de débogage intra-thread. Le code débogué et le code utilisant Debugger pour l'observer doivent tourner dans même thread. Les outils Cross-thread, cross-process, et cross-device doivent utiliser Debugger pour observer le code débogué depuis le même thread, et ensuite gérer toute communication nécessaire eux-mêmes. ( Les outils de développement de Firefox ont un protocole défini pour cet usage.)

Dans Gecko, L'API du Debugger est disponible uniquement pour du code chrome. Par définition, L'API ne devrait pas introduire de failles de sécurité, elle pourrait donc en principe être disponible pour le contenu normal également. Cependant il est difficile de justifier les risques de sécurité du nouvel angle d'attaque que cela entrainerait.

L'API du Debugger ne peut actuellement pas observer du JavaScript auto-hébergé ( "self-hosted" ). Cel n'est pas du au design de l'API, mais simplement au fait que que l'infra structure auto-hébergée n'est pas préparé aux types d'invasions que l'API mène.

Instances Debugger et Shadow Objects

Debugger reflète chaque aspect de l'état du code débogué en tant que valeur JavaScript. Pas uniquement des valeurs JavaScript basiques comme des objets ou des primitives, mais également des des stack frames,des environnements, des scripts, et des unités de compilation, qui ne sont normalement pas accessible en tant qu'objet à part entière.

Voici un programme JavaScript en train de faire tourner une fonction callback de timer :

A running JavaScript program and its Debugger shadows

Un programme JavaScript en cours d'exécution ainsi que ses Debugger shadows

Ce diagramme montre les différents types de shadow objects qui composent l'API du Debugger (celle-ci suit quelques conventions générales):

  • Un Debugger.Object représente un objet du code débogué, permettant ainsi une API reflection-oriented qui empêche le debugger d'invoquer accidentellement des getters, des setters, des pièges proxy, et ainsi de suite.
  • Un Debugger.Script représente un bloc de code JavaScript. Il s'agit soit du corps d'une fonction ou un script top-level. Avec un Debugger.Script donné, il est possible de placer des points d'arrêt, se déplacer entre plusieurs positions de source et offsets de bytecode (une déviation au principe “source level”), et de trouver d'autres caractéristiques statiques du code.
  • Un Debugger.Frame représente une stack frame en cours d'exécution. Il est possible de les utiliser pour parcourir la stack et trouver chaque script et environnement de la frame. Il est également possible de définir les handlers onStep et onPop sur les frames.
  • Un Debugger.Environment représente un environnement en associant les noms de variables avec leur emplacement de stockage. Les environnements peuvent appartenir à une stack frame en cours d'exécution capturée par une closure, ou représenter certaines propriétés d'un objet global en tant que variables.

L'instance du Debugger en elle-même n'est pas vraiment une ombre de quoi que ce soit dans le code débogué. Elle est ce qui maintient l'ensemble des objets globaux qui sont considérés comme le code débogué. Un Debugger n'observe que l'exécution se passant dans la portée de ces objets globaux. Il est possible de définir des fonctions qui vont être appelées lorsqu'une nouvelle stack frame est poussée : quand le code est chargé; et ainsi de suite.

Les instances Debugger.Source représentent les unités de compilation JavaScript. Un Debugger.Source peut fournir une copie complète de tout son code source, et expliquer comment ce code est entré dans le système, que cela soit par un appel à eval, un élémément script , ou d'autres méthodes. Un Debugger.Script pointe vers le Debugger.Source duquel il est dérivé.

L'instance Debugger.Memory du Debugger, contient les méthodes et les ancêtres pour observer l'usage mémoire di code débogué.

Tout ces types suivent des conventions générales. Il est recommandé de regarder ces conventions avant de se concentrer sur la spécification d'un type en particulier.

Tous les shadow objects sont uniques à un Debugger et un référent. Pour un a Debugger, donné, il y a exactement un Debugger.Object qui renvoie à un objet du code débogué en particulier, et exactement un Debugger.Frame pour une stack frame en particulier, et ainsi de suite. Ainsi donc un outil peut stocker les metadata du référent d'une ombre en tant que propriété de l'ombre elle-même, et est sûr de pouvoir trouver ce metadata à nouveau s’il rencontre le même référent. Et vu que les ombres sont propres à l'instance du Debugger, les outils peuvent faire cela sans avoir à s'inquiéter d'interférer avec d'autres outils qui utilisent leurs propres instances du Debugger.

Exemples

Voici des choses qu'il est possible d'essayer, soit même, afin de voir certaines fonctionnalités du Debugger :

Fonctionalitées spécifiques à Gecko

Alors que le coeur de L'API du Debugger ne contient que des concepts communs à toutes les implémentations JavaScript, L'API contient également des fonctionnalités spécifiques à Gecko :

  • [Global tracking][global] supporte le débogage de tout le code tournant dans une instance Gecko d'un seul coup-- le modèle ‘chrome debugging’.
  • [Object wrapper][wrapper] fonctions qui aident à la manipulation de références d'objets qui transgressent les limites des privilèges.

Source Metadata

     251fccc1f62b

Généré depuis le fichier :
js/src/doc/Debugger/Debugger-API.md
Watermark :
sha256:600a6f2c928e1b4cf193298c8efc679a849c41d00ef37e47895aef4dd870016d
Changeset :

Étiquettes et contributeurs liés au document

 Contributeurs à cette page : maximelore
 Dernière mise à jour par : maximelore,