Partilhar via

Diagnóstico e instrumentação

  • Artigo

A AOT nativa compartilha alguns, mas não todos, recursos de diagnóstico e instrumentação com o CoreCLR. Devido à rica seleção de utilitários de diagnóstico do CoreCLR, às vezes é apropriado diagnosticar e depurar problemas no CoreCLR. Os aplicativos que são compatíveis com trim não devem ter diferenças comportamentais, portanto, as investigações geralmente se aplicam a ambos os tempos de execução. No entanto, algumas informações só podem ser coletadas após a publicação, portanto, o Native AOT também fornece ferramentas de diagnóstico pós-publicação.

Suporte ao diagnóstico AOT nativo do .NET 8

A tabela a seguir resume os recursos de diagnóstico suportados para implantações AOT nativas:

Caraterística Totalmente suportado Parcialmente suportado Não suportado
Observabilidade e telemetria
Diagnósticos em tempo de desenvolvimento
Depuração nativa
Criação de perfil da CPU
Análise de heap

Observabilidade e telemetria

A partir do .NET 8, o tempo de execução nativo do AOT suporta EventPipe, que é a camada base usada por muitas bibliotecas de registro em log e rastreamento. Você pode interagir com o EventPipe diretamente por meio de APIs como EventSource.WriteEvent ou pode usar bibliotecas criadas sobre isso, como OpenTelemetry. O suporte ao EventPipe também permite que ferramentas de diagnóstico .NET, como dotnet-trace, dotnet-counters e dotnet-monitor, funcionem perfeitamente com aplicativos AOT ou CoreCLR nativos. O EventPipe é um componente opcional na AOT nativa. Para incluir o suporte a EventPipe, defina a EventSourceSupport propriedade MSBuild como true.

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

A AOT nativa fornece suporte parcial para alguns provedores de eventos bem conhecidos. Nem todos os eventos de tempo de execução são suportados na AOT nativa.

Diagnósticos em tempo de desenvolvimento

As ferramentas da CLI do .NET (dotnet SDK) e o Visual Studio oferecem comandos separados para build e publish. build (ou Start no Visual Studio) usa CoreCLR. Cria apenas publish um aplicativo AOT nativo. Publicar seu aplicativo como AOT nativo produz um aplicativo que foi compilado antecipadamente no tempo (AOT) para código nativo. Como mencionado anteriormente, nem todas as ferramentas de diagnóstico funcionam perfeitamente com aplicativos AOT nativos publicados no .NET 8. No entanto, todas as ferramentas de diagnóstico do .NET estão disponíveis para desenvolvedores durante o estágio de criação do aplicativo. Recomendamos desenvolver, depurar e testar os aplicativos como de costume e publicar o aplicativo de trabalho com AOT nativo como uma das últimas etapas.

Depuração nativa

Quando você executa seu aplicativo durante o desenvolvimento, como dentro do Visual Studio, ou com dotnet run, dotnet buildou dotnet test, ele é executado no CoreCLR por padrão. No entanto, se PublishAot estiver presente no arquivo de projeto, o comportamento deve ser o mesmo entre CoreCLR e AOT nativo. Essa característica permite que você use o mecanismo de depuração gerenciado padrão do Visual Studio para desenvolvimento e teste.

Após a publicação, os aplicativos AOT nativos são verdadeiros binários nativos. O depurador gerenciado não funcionará neles. No entanto, o compilador AOT nativo gera arquivos executáveis totalmente nativos que os depuradores nativos podem depurar em sua plataforma de escolha (por exemplo, WinDbg ou Visual Studio no Windows e gdb ou lldb em sistemas Unix-like).

O compilador AOT nativo gera informações sobre números de linha, tipos, locais e parâmetros. O depurador nativo permite inspecionar o rastreamento de pilha e variáveis, entrar ou ultrapassar linhas de origem ou definir pontos de interrupção de linha.

Para depurar exceções gerenciadas, defina um ponto de interrupção no RhThrowEx método, que é chamado sempre que uma exceção gerenciada é lançada. A exceção é armazenada no rcx ou x0 registo. Se o depurador oferecer suporte à exibição de objetos C++, você poderá converter o registro para S_P_CoreLib_System_Exception* para ver mais informações sobre a exceção.

Coletar um arquivo de despejo para um aplicativo AOT nativo envolve algumas etapas manuais no .NET 8.

Notas específicas do Visual Studio

Você pode iniciar um executável compilado por AOT nativo no depurador do Visual Studio abrindo-o no IDE do Visual Studio. Você precisa abrir o próprio executável no Visual Studio.

Para definir um ponto de interrupção que quebra sempre que uma exceção é lançada, escolha a opção Pontos de interrupção no menu Depurar > Windows . Na nova janela, selecione Novo > ponto de interrupção de função . Especifique RhThrowEx como o Nome da Função e deixe a opção Idioma em Todos os Idiomas (não selecione C#).

Para ver qual exceção foi lançada, inicie a depuração (Debug > Start Debugging ou F5), abra a janela Watch (Debug > Windows > Watch) e adicione a seguinte expressão como um dos relógios: (S_P_CoreLib_System_Exception*)@rcx. Este mecanismo aproveita o fato de que, no momento RhThrowEx em que é chamado, o registro de CPU x64 RCX contém a exceção lançada. Você também pode colar a expressão na janela Immediate; A sintaxe é a mesma dos relógios.

Importância do arquivo de símbolos

Ao publicar, o compilador AOT nativo produz um arquivo executável e um arquivo de símbolo. A depuração nativa e atividades relacionadas, como criação de perfil, exigem acesso ao arquivo de símbolo nativo. Se esse arquivo não estiver presente, você pode ter resultados degradados ou quebrados.

Para obter informações sobre o nome e o local do arquivo de símbolo, consulte Informações de depuração nativas.

Criação de perfil da CPU

Ferramentas específicas da plataforma, como PerfView e Perf, podem ser usadas para coletar amostras de CPU de um aplicativo AOT nativo.

Análise de heap

Atualmente, a análise de heap gerenciada não é suportada na AOT nativa. Ferramentas de análise de heap como dotnet-gcdump, PerfView e ferramentas de análise de heap do Visual Studio não funcionam no AOT nativo no .NET 8.