Fix relative paths

Author: ivanpovazan

docs/core/deploying/native-aot/diagnostics/desktop-platforms.md

@@ -10,15 +10,15 @@ ms.date: 08/07/2023
 
 ## Observability and telemetry
 
-As of .NET 8, the Native AOT runtime supports [EventPipe](../../diagnostics/eventpipe.md), which is the base layer used by many logging and tracing libraries. You can interface with EventPipe directly through APIs like `EventSource.WriteEvent` or you can use libraries built on top, like [OpenTelemetry](../../diagnostics/observability-with-otel.md). EventPipe support also allows .NET diagnostic tools like [dotnet-trace](../../diagnostics/dotnet-trace.md), [dotnet-counters](../../diagnostics/dotnet-counters.md), and [dotnet-monitor](../../diagnostics/dotnet-monitor.md) to work seamlessly with Native AOT or CoreCLR applications. EventPipe is an optional component in Native AOT. To include EventPipe support, set the `EventSourceSupport` MSBuild property to `true`.
+As of .NET 8, the Native AOT runtime supports [EventPipe](../../../diagnostics/eventpipe.md), which is the base layer used by many logging and tracing libraries. You can interface with EventPipe directly through APIs like `EventSource.WriteEvent` or you can use libraries built on top, like [OpenTelemetry](../../../diagnostics/observability-with-otel.md). EventPipe support also allows .NET diagnostic tools like [dotnet-trace](../../../diagnostics/dotnet-trace.md), [dotnet-counters](../../../diagnostics/dotnet-counters.md), and [dotnet-monitor](../../../diagnostics/dotnet-monitor.md) to work seamlessly with Native AOT or CoreCLR applications. EventPipe is an optional component in Native AOT. To include EventPipe support, set the `EventSourceSupport` MSBuild property to `true`.
 
 ```xml
 <PropertyGroup>
     <EventSourceSupport>true</EventSourceSupport>
 </PropertyGroup>
 ```
 
-Native AOT provides partial support for some [well-known event providers](../../diagnostics/well-known-event-providers.md). Not all [runtime events](../../../fundamentals/diagnostics/runtime-events.md) are supported in Native AOT.
+Native AOT provides partial support for some [well-known event providers](../../../diagnostics/well-known-event-providers.md). Not all [runtime events](../../../../fundamentals/diagnostics/runtime-events.md) are supported in Native AOT.
 
 ## Development-time diagnostics
 
@@ -41,7 +41,7 @@ The Native AOT compiler generates information about line numbers, types, locals,
 To debug managed exceptions, set a breakpoint on the `RhThrowEx` method, which is called whenever a managed exception is thrown. The exception is stored in the `rcx` or `x0` register. If your debugger supports viewing C++ objects, you can cast
 the register to `S_P_CoreLib_System_Exception*` to see more information about the exception.
 
-Collecting a [dump](../../diagnostics/dumps.md) file for a Native AOT application involves some manual steps in .NET 8.
+Collecting a [dump](../../../diagnostics/dumps.md) file for a Native AOT application involves some manual steps in .NET 8.
 
 ### Visual Studio-specific notes
 
@@ -55,12 +55,12 @@ To see what exception was thrown, start debugging (**Debug > Start Debugging** o
 
 When publishing, the Native AOT compiler produces both an executable and a symbol file. Native debugging, and related activities like profiling, require access to the native symbol file. If this file isn't present, you might have degraded or broken results.
 
-For information about the name and location of the symbol file, see [Native debug information](index.md#native-aot-deployment).
+For information about the name and location of the symbol file, see [Native debug information](../index.md#native-aot-deployment).
 
 ## CPU profiling
 
 Platform-specific tools like [PerfView](https://github.com/microsoft/perfview) and [Perf](https://perf.wiki.kernel.org/index.php/Main_Page) can be used to collect CPU samples of a Native AOT application.
 
 ## Heap analysis
 
-Managed heap analysis isn't currently supported in Native AOT. Heap analysis tools like [dotnet-gcdump](../../diagnostics/dotnet-gcdump.md), [PerfView](https://github.com/microsoft/perfview), and Visual Studio heap analysis tools don't work in Native AOT in .NET 8.
+Managed heap analysis isn't currently supported in Native AOT. Heap analysis tools like [dotnet-gcdump](../../../diagnostics/dotnet-gcdump.md), [PerfView](https://github.com/microsoft/perfview), and Visual Studio heap analysis tools don't work in Native AOT in .NET 8.

docs/core/deploying/native-aot/diagnostics/diagnostics.md renamed to docs/core/deploying/native-aot/diagnostics/index.md

@@ -8,7 +8,7 @@ ms.date: 08/07/2023
 
 # Diagnostics and instrumentation
 
-Native AOT shares some, but not all, diagnostics and instrumentation capabilities with CoreCLR on desktop platforms and Mono on mobile platforms. Because of CoreCLR's and Mono's rich selection of diagnostic utilities, it's sometimes appropriate to diagnose and debug problems in CoreCLR or Mono, rather than with Native AOT. Apps that are [trim-compatible](../trimming/prepare-libraries-for-trimming.md) shouldn't have behavioral differences, so investigations often apply between runtimes. Nonetheless, some information can only be gathered after publishing, so Native AOT also provides post-publish diagnostic tooling.
+Native AOT shares some, but not all, diagnostics and instrumentation capabilities with CoreCLR on desktop platforms and Mono on mobile platforms. Because of CoreCLR's and Mono's rich selection of diagnostic utilities, it's sometimes appropriate to diagnose and debug problems in CoreCLR or Mono, rather than with Native AOT. Apps that are [trim-compatible](../../trimming/prepare-libraries-for-trimming.md) shouldn't have behavioral differences, so investigations often apply between runtimes. Nonetheless, some information can only be gathered after publishing, so Native AOT also provides post-publish diagnostic tooling.
 
 ## Native AOT diagnostic support
 

docs/core/deploying/native-aot/index.md

@@ -115,7 +115,7 @@ By default, Native AOT publishing produces debug information in a separate file:
 - Windows: *.pdb*
 - macOS: *.dSYM* folder
 
-The debug file is necessary for running the app under the [debugger or inspecting crash dumps](./diagnostics.md#importance-of-the-symbol-file). On Unix-like platforms, set the `StripSymbols` property to `false` to include the debug information in the native binary. Including debug information makes the native binary larger.
+The debug file is necessary for running the app under the [debugger or inspecting crash dumps](./diagnostics/desktop-platforms.md#importance-of-the-symbol-file). On Unix-like platforms, set the `StripSymbols` property to `false` to include the debug information in the native binary. Including debug information makes the native binary larger.
 
 ```xml
 <PropertyGroup>
@@ -136,7 +136,7 @@ Native AOT apps have the following limitations:
 - Apps include required runtime libraries (just like [self-contained apps](../index.md#publish-self-contained), increasing their size as compared to framework-dependent apps).
 - <xref:System.Linq.Expressions> always use their interpreted form, which is slower than run-time generated compiled code.
 - Not all the runtime libraries are fully annotated to be Native AOT compatible. That is, some warnings in the runtime libraries aren't actionable by end developers.
-- [Diagnostic support for debugging and profiling](./diagnostics.md) with some limitations.
+- [Diagnostic support for debugging and profiling](./diagnostics/index.md) with some limitations.
 - Support for some ASP.NET Core features. For more information, see [ASP.NET Core support for Native AOT](/aspnet/core/fundamentals/native-aot/).
 
 The publish process analyzes the entire project and its dependencies for possible limitations. Warnings are issued for each limitation the published app might encounter at run time.