Diagnostyka i instrumentacja

Natywna funkcja AOT udostępnia niektóre, ale nie wszystkie funkcje diagnostyki i instrumentacji za pomocą biblioteki CoreCLR. Ze względu na bogaty wybór narzędzi diagnostycznych CoreCLR czasami jest odpowiedni do diagnozowania i debugowania problemów w CoreCLR. Aplikacje zgodne z przycinanie nie powinny mieć różnic behawioralnych, dlatego badania często mają zastosowanie do obu środowisk uruchomieniowych. Niemniej jednak niektóre informacje można zebrać tylko po opublikowaniu, dlatego natywna usługa AOT udostępnia również narzędzia diagnostyczne po opublikowaniu.

.NET 8 Native AOT — obsługa diagnostyczna

W poniższej tabeli przedstawiono podsumowanie funkcji diagnostycznych obsługiwanych w przypadku wdrożeń natywnych funkcji AOT:

Funkcja	W pełni obsługiwane	Zaimportowano częściowo	Nieobsługiwane
Obserwowanie i telemetria		✔️Częściowo obsługiwane
Diagnostyka czasu programowania	✔️W pełni obsługiwane
Debugowanie natywne		✔️Częściowo obsługiwane
Profilowanie procesora CPU		✔️Częściowo obsługiwane
Analiza stert			❌Nieobsługiwane

Obserwowanie i telemetria

Od platformy .NET 8 środowisko uruchomieniowe natywnej AOT obsługuje platformę EventPipe, która jest warstwą podstawową używaną przez wiele bibliotek rejestrowania i śledzenia. Interfejs z interfejsem EventPipe można połączyć bezpośrednio za pośrednictwem interfejsów API, takich jak EventSource.WriteEvent lub można użyć bibliotek utworzonych na początku, takich jak OpenTelemetry. Obsługa interfejsu EventPipe umożliwia również korzystanie z narzędzi diagnostycznych platformy .NET, takich jak dotnet-trace, dotnet-counters i dotnet-monitor , bezproblemowe działanie z natywnymi aplikacjami AOT lub CoreCLR. EventPipe jest opcjonalnym składnikiem w natywnej usłudze AOT. Aby uwzględnić obsługę elementu EventPipe, ustaw EventSourceSupport właściwość MSBuild na truewartość .

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

Natywna funkcja AOT zapewnia częściową obsługę niektórych dobrze znanych dostawców zdarzeń. Nie wszystkie zdarzenia środowiska uruchomieniowego są obsługiwane w natywnej usłudze AOT.

Diagnostyka czasu programowania

Narzędzia interfejsu wiersza polecenia platformy .NET (dotnet zestaw SDK) i program Visual Studio oferują oddzielne polecenia dla i buildpublish. build (lub Start w programie Visual Studio) używa coreCLR. Tworzy tylko publish natywną aplikację AOT. Publikowanie aplikacji jako natywnej funkcji AOT powoduje utworzenie aplikacji, która została skompilowana przed czasem (AOT) do kodu natywnego. Jak wspomniano wcześniej, nie wszystkie narzędzia diagnostyczne działają bezproblemowo z opublikowanymi natywnymi aplikacjami AOT na platformie .NET 8. Jednak wszystkie narzędzia diagnostyczne platformy .NET są dostępne dla deweloperów podczas etapu tworzenia aplikacji. Zalecamy tworzenie, debugowanie i testowanie aplikacji w zwykły sposób oraz publikowanie aplikacji roboczej z natywną usługą AOT jako jednym z ostatnich kroków.

Debugowanie natywne

Po uruchomieniu aplikacji podczas programowania, na przykład w programie Visual Studio lub dotnet runw systemie , dotnet builddomyślnie dotnet testjest ona uruchamiana w usłudze CoreCLR. Jeśli jednak PublishAot występuje w pliku projektu, zachowanie powinno być takie samo między rdzeniami CoreCLR i natywną funkcją AOT. Ta cecha umożliwia używanie standardowego aparatu debugowania zarządzanego programu Visual Studio do programowania i testowania.

Po opublikowaniu natywne aplikacje AOT są natywnymi plikami binarnymi. Zarządzany debuger nie będzie nad nimi działać. Jednak natywny kompilator AOT generuje w pełni natywne pliki wykonywalne, które natywne debugery mogą debugować na wybranej platformie (na przykład WinDbg lub Visual Studio w systemach windows i gdb lub lldb w systemach przypominających system Unix).

Kompilator natywnej funkcji AOT generuje informacje o numerach wierszy, typach, ustawieniach lokalnych i parametrach. Natywny debuger umożliwia inspekcję śledzenia i zmiennych stosu, przechodzenie do wierszy źródłowych lub ustawianie punktów przerwania wiersza.

Aby debugować wyjątki zarządzane, ustaw punkt przerwania w metodzie RhThrowEx , która jest wywoływana za każdym razem, gdy jest zgłaszany wyjątek zarządzany. Wyjątek jest przechowywany w rejestrze rcx lub x0 . Jeśli debuger obsługuje wyświetlanie obiektów języka C++, możesz rzutować rejestr, aby S_P_CoreLib_System_Exception* wyświetlić więcej informacji o wyjątku.

Zbieranie pliku zrzutu dla natywnej aplikacji AOT obejmuje kilka ręcznych kroków na platformie .NET 8.

Uwagi specyficzne dla programu Visual Studio

Plik wykonywalny skompilowany przy użyciu natywnego środowiska AOT można uruchomić w debugerze programu Visual Studio, otwierając go w środowisku IDE programu Visual Studio. Musisz otworzyć plik wykonywalny w programie Visual Studio.

Aby ustawić punkt przerwania, który ulega awarii za każdym razem, gdy zostanie zgłoszony wyjątek, wybierz opcję Punkty przerwania z menu Debuguj > system Windows. W nowym oknie wybierz pozycję Nowy > punkt przerwania funkcji . Określ RhThrowEx jako nazwę funkcji i pozostaw opcję Język we wszystkich językach (nie wybieraj języka C#).

Aby zobaczyć, jaki wyjątek został zgłoszony, rozpocznij debugowanie (Debuguj > rozpocznij debugowanie debugowania lub klawisz F5), otwórz okno Obserwowanie (Debugowanie > usługi Windows > Watch) i dodaj następujące wyrażenie jako jedno z zegarków: (S_P_CoreLib_System_Exception*)@rcx. Ten mechanizm wykorzystuje fakt, że w czasie RhThrowEx jest wywoływany rejestr procesorów x64 RCX zawiera zgłoszony wyjątek. Możesz również wkleić wyrażenie do okna Natychmiastowe; składnia jest taka sama jak w przypadku zegarków.

Znaczenie pliku symboli

Podczas publikowania kompilator natywny AOT tworzy zarówno plik wykonywalny, jak i plik symboli. Debugowanie natywne i powiązane działania, takie jak profilowanie, wymagają dostępu do natywnego pliku symboli. Jeśli ten plik nie jest obecny, może wystąpić obniżenie wydajności lub uszkodzenie wyników.

Aby uzyskać informacje o nazwie i lokalizacji pliku symboli, zobacz Native debug information (Informacje o debugowaniu natywnym).

Profilowanie procesora CPU

Narzędzia specyficzne dla platformy, takie jak PerfView i Perf , mogą służyć do zbierania przykładów procesora CPU dla natywnej aplikacji AOT.

Analiza stert

Analiza sterty zarządzanej nie jest obecnie obsługiwana w natywnej usłudze AOT. Narzędzia do analizy sterty, takie jak dotnet-gcdump, PerfView i narzędzia analizy sterty programu Visual Studio, nie działają w natywnym AOT na platformie .NET 8.