Diagnostics et instrumentation

  • Article

L’AOT natif partage certaines fonctionnalités, mais pas toutes, de diagnostics et d’instrumentation avec CoreCLR. En raison de la sélection enrichie d’utilitaires de diagnostic de CoreCLR, il est parfois approprié de diagnostiquer et de déboguer des problèmes dans CoreCLR. Les applications compatibles avec le découpage ne doivent pas avoir de différences de comportement afin que les enquêtes s’appliquent régulièrement aux deux runtimes. Néanmoins, certaines informations ne peuvent être collectées qu’après la publication. C’est pour cela que l’AOT natif fournit également des outils de diagnostic post-publication.

Prise en charge des diagnostics AOT natifs .NET 8

Le tableau ci-dessous récapitule les fonctionnalités de diagnostic prises en charge pour les déploiements AOT natifs :

Fonctionnalité Entièrement prise en charge Partiellement prise en charge Non pris en charge
Observabilité et télémétrie
Diagnostics au moment du développement
Débogage natif
Profilage du processeur
Analyse de tas

Observabilité et télémétrie

À compter de .NET 8, le runtime AOT natif prend en charge EventPipe, qui est la couche de base utilisée par de nombreuses bibliothèques de journalisation et de suivi. Vous pouvez effectuer une interface avec EventPipe directement via des API telles que EventSource.WriteEvent ou des bibliothèques basées sur celles-ci, comme OpenTelemetry. La prise en charge d’EventPipe permet également aux outils de diagnostic .NET, comme dotnet-trace, dotnet-counters et dotnet-monitor, de fonctionner en toute transparence avec les applications AOT natives ou CoreCLR. EventPipe est un composant facultatif dans AOT natif. Pour inclure la prise en charge d’EventPipe, définissez la propriété MSBuild EventSourceSupport sur true.

<PropertyGroup>
    <EventSourceSupport>true</EventSourceSupport>
</PropertyGroup>

Le mode AOT natif fournit une prise en charge partielle de certains fournisseurs d’événements connus. Les événements de runtime ne sont pas tous pris en charge dans AOT natif.

Diagnostics au moment du développement

Les outils CLI .NET (SDK dotnet) et Visual Studio offrent des commandes distinctes pour build et publish. build (ou Start dans Visual Studio) utilise CoreCLR. Seul publish crée une application AOT native. La publication de votre application en tant qu’application AOT native produit une application qui a été compilée à l’avance (AOT) en code natif. Comme mentionné antérieurement, les outils de diagnostic ne fonctionnent pas tous en toute transparence avec les applications AOA natives publiées dans .NET 8. Toutefois, tous les outils de diagnostic .NET sont disponibles pour les développeurs pendant la phase de génération d’application. Nous vous recommandons de développer, de déboguer et de tester les applications comme d’habitude et de terminer par la publication de l’application de travail en mode AOT natif.

Débogage natif

Lorsque vous exécutez votre application pendant le développement, comme dans Visual Studio ou avec dotnet run, dotnet build ou dotnet test, elle s’exécute sur CoreCLR par défaut. Toutefois, si PublishAot est présent dans le fichier projet, le comportement doit être le même entre CoreCLR et AOT natif. Cette caractéristique vous permet d’utiliser le moteur de débogage managé Visual Studio standard pour le développement et les tests.

Après la publication, les applications AOT natives sont des fichiers binaires natifs. Le débogueur managé n’y fonctionne pas. Toutefois, le compilateur AOA natif génère des fichiers exécutables entièrement natifs que les débogueurs natifs peuvent déboguer sur la plateforme de votre choix (par exemple, WinDbg ou Visual Studio sur Windows et GDB ou LLDB sur des systèmes de type Unix).

Le compilateur AOT natif génère des informations sur les numéros de ligne, les types, les variables locales et les paramètres. Le débogueur natif permet d’inspecter la trace et les variables, d’effectuer un pas à pas détaillé des lignes sources ou de définir des points d’arrêt de ligne.

Pour déboguer des exceptions managées, définissez un point d’arrêt sur la méthode RhThrowEx, qui est appelée chaque fois qu’une exception managée est levée. L’exception est stockée dans le registre rcx ou x0. Si votre débogueur prend en charge l’affichage des objets C++, vous pouvez caster le registre pour S_P_CoreLib_System_Exception* afin d’afficher plus d’informations sur l’exception.

La collecte d’un fichier de vidage pour une application AOT native implique des étapes manuelles dans .NET 8.

Notes spécifiques à Visual Studio

Vous pouvez lancer un exécutable compilé par AOT natif sous le débogueur Visual Studio en l’ouvrant dans l’IDE Visual Studio. Vous devez ouvrir l’exécutable lui-même dans Visual Studio.

Pour définir un point d’arrêt qui s’arrête chaque fois qu’une exception est levée, choisissez l’option Points d’arrêt dans le menu Debug > Windows. Dans la nouvelle fenêtre, sélectionnez Nouveau > Point d’arrêt de fonction. Spécifiez RhThrowEx comme nom de la fonction et laissez l’option Langage sur Tous les langages (ne sélectionnez pas C#).

Pour voir quelle exception a été levée, démarrez le débogage (Déboguer > Démarrer le débogage ou F5), ouvrez la fenêtre Espion (Déboguer > Fenêtres > Espion ) et ajoutez l’expression suivante comme l’un des espions :(S_P_CoreLib_System_Exception*)@rcx. Ce mécanisme tire parti du fait qu’au moment de l’appel de RhThrowEx, le registre RCX du processeur x64 contient l’exception levée. Vous pouvez également coller l’expression dans la fenêtre Exécution ; la syntaxe est la même que pour les espions.

Importance du fichier de symboles

Lors de la publication, le compilateur AOT natif produit un fichier exécutable et un fichier de symboles. Le débogage natif et les activités associées comme le profilage nécessitent l’accès au fichier de symboles natif. Si ce fichier n’est pas présent, il est possible que vous ayez détérioré ou endommagé les résultats.

Pour plus d’informations sur le nom et l’emplacement du fichier de symboles, consultez les Informations de débogage natives.

Profilage du processeur

Des outils spécifiques à la plateforme tels que PerfView et Perf peuvent être utilisés pour collecter des exemples de processeur d’une application AOT native.

Analyse de tas

L’analyse de tas managée n’est actuellement pas prise en charge dans AOA natif. Les outils d’analyse de tas tels que dotnet-gcdump, PerfView et les outils d’analyse de tas Visual Studio ne fonctionnent pas en mode AOT natif dans .NET 8.