Points de trace statiques et dynamiques en mode noyau

En utilisant TRACE_EVENT et UST, il est maintenant possible d'insérer des points d'instrumentation statiques sous Linux en modes noyau et usager respectivement, tout en minimisant l'impact sur la performance du système instrumenté. Toutefois, ces points d'instrumentation peuvent parfois s'avérer insuffisants pour diagnostiquer les origines d'un problème. L'instrumentation dynamique répond à ce besoin en rendant possible l'insertion de points de trace supplémentaires au moment de l'exécution. Récemment, les points de trace dynamiques ont été implémentés dans GDB et GDBServer en mode usager. En utilisant cette technique, on est capable d'associer un ensemble d'actions à n'importe quelle adresse dans le code du programme. Ces actions peuvent servir à collecter les valeurs des registres au moment où le point de trace est rencontré et aussi à évaluer des expressions complexes qui peuvent employer les variables accessibles à partir de cet endroit dans le programme. GDB étant capable de lire les informations de débogage et de localiser l'emplacement de chaque variable, on peut faire référence à une variable dans ces expressions en utilisant directement son nom sans se soucier de son emplacement. Les points de trace statiques et dynamiques de GDB peuvent être conditionnels. Dans ce cas, une expression est utilisée comme condition. Les expressions utilisées dans les conditions et expressions sont converties en code intermédiaire qui est interprété par GDBServer au moment où le point de trace est rencontré. L'intérêt du code intermédiaire est de garantir la portabilité entre les différentes architectures. Cependant, GDBServer peut le transformer en code natif afin d'améliorer la performance. En effet, exécuter du code natif est souvent plus rapide que d'avoir à identifier et exécuter des instructions une par une. Plus récemment, le module KGTP a été proposé comme contribution au noyau Linux. Il se base sur Kprobes pour implémenter les points de trace dynamiques de GDB en mode noyau et communique avec celui-ci en utilisant le protocole RSP (Remote Serial Protocol). Il est seulement capable d'interpréter le code intermédiaire produit par GDB et ne peut pas faire de conversion en code natif. L'objectif de ce travail est d'implémenter un convertisseur en mode noyau pour KGTP pour traduire le code intermédiaire en code natif pour les conditions et aussi les actions afin d'améliorer la performance des points de trace dynamiques. Aussi, nous allons intégrer TRACE_EVENT et GDB en mode noyau à travers KGTP pour être capable, tout comme en mode usager, de lister, activer et désactiver les points de trace statiques du noyau. Le même convertisseur de code intermédiaire à code natif est utilisé avec les points de trace statiques pour pouvoir leur associer des conditions et des expressions supplémentaires à exécuter. Ces expressions doivent elles aussi être capables d'utiliser toutes les variables accessibles au niveau du point de trace statique.

Abstract

With kernel static tracepoints defined using TRACE_EVENT and user-space tracepoints through the UST library, it is now possible to add instrumentation and obtain a low overhead trace of the whole system. However, these static tracepoints may be insufficient to diagnose the source of a problem. Dynamic instrumentation fills the gap by making it possible to insert additional tracepoints in other locations at run time. Recently, GDB was enhanced to support dynamic tracepoints in user-space. Using this feature, tracepoints can be defined in almost every location in a program. A set of actions can be associated to each tracepoint. These actions may be used to collect the values of the registers at the time the tracepoint was hit or to evaluate user-defined expressions. These expressions may be complex and can employ all the program variables accessible from the tracepoint location. GDB being able to read the program debug information and to locate variables, we can refer to variables in these expressions by their names without having to care about their locations. GDB static and dynamic tracepoints may be conditional. In this case, expressions can be used as conditions. In order to simplify evaluation, GDB converts expressions used in conditions and actions to bytecode which is interpreted each time the corresponding tracepoint is hit. Moreover, in some situations, GDB converts the conditions' bytecodes into native code in order to improve performance. More recently, the KGTP kernel module was submitted as a contribution to the Linux kernel. It uses Kprobes to insert GDB dynamic tracepoints into the kernel, implements the RSP (Remote Serial Protocol) to communicate with GDB and can interpret the bytecode used by GDB to define conditions and actions, but is unable to convert this bytecode to native code. The goal of this work is to extend the KGTP module by implementing a bytecode to native code converter in kernel space for both conditions and actions. GDB will also be integrated with TRACE_EVENT through KGTP in order to be able to list, enable and disable the kernel static tracepoints. Expressions may be used in conditions and additional actions. These expressions will be converted to native code and may employ all the variables accessible from the static tracepoint location.