* [FAQ](documentation/FAQ.md) - Frequently asked questions.
* [The LLDB Debugger](http://lldb.llvm.org/index.html) - More information about lldb.
* [SOS](https://msdn.microsoft.com/en-us/library/bb190764(v=vs.110).aspx) - More information about SOS.
-* [Debugging CoreCLR](https://github.com/dotnet/runtime/blob/master/docs/workflow/debugging/coreclr/debugging.md) - Instructions for debugging .NET Core and the CoreCLR runtime.
+* [Debugging CoreCLR](https://github.com/dotnet/runtime/blob/main/docs/workflow/debugging/coreclr/debugging.md) - Instructions for debugging .NET Core and the CoreCLR runtime.
* [dotnet/runtime](https://github.com/dotnet/runtime) - Source for the .NET Core runtime.
* [Official Build Instructions](documentation/building/official-build-instructions.md) - Internal official build instructions.
## Build Status
-[](https://dnceng.visualstudio.com/public/_build/latest?definitionId=72&branchName=master)
+[](https://dnceng.visualstudio.com/public/_build/latest?definitionId=72&branchName=main)
[//]: # (End current test results)
autoCancel: true
branches:
include:
- - master
- main
- release/*
paths:
SOS does not support the current target architecture 'arm32' (0x01c4). A 32 bit target may require a 32 bit debugger or vice versa. In general, try to use the same bitness for the debugger and target process.
```
- You may need a different bitness of the Windows (windbg/cdb) debugger or dotnet-dump. If you are running an x64 (64 bit), try an x86 (32 bit) version. The easiest way to get an x86 version of dotnet-dump is installing the "single-file" version [here](https://aka.ms/dotnet-dump/win-x86). For more information on single-file tools see [here](https://github.com/dotnet/diagnostics/blob/master/documentation/single-file-tools.md#single-file-diagnostic-tools).
+ You may need a different bitness of the Windows (windbg/cdb) debugger or dotnet-dump. If you are running an x64 (64 bit), try an x86 (32 bit) version. The easiest way to get an x86 version of dotnet-dump is installing the "single-file" version [here](https://aka.ms/dotnet-dump/win-x86). For more information on single-file tools see [here](https://github.com/dotnet/diagnostics/blob/main/documentation/single-file-tools.md#single-file-diagnostic-tools).
The following instructions will install the required packages. This only needs to be done once per machine. These instructions assume that you already have "sudo" installed. It is also recommended to create a github fork of the diagnostics repo and cloning that instead of https://github.com/dotnet/diagnostics.git directly.
-To build or cross build for ARM on Windows or Linux see the instructions [here](https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/cross-building.md#generating-the-rootfs) in the runtime repo. You will need to clone the runtime [repo](https://github.com/dotnet/runtime.git) and build the appropriate "rootfs" for arm or arm64 using these instructions. You only need to do this once.
+To build or cross build for ARM on Windows or Linux see the instructions [here](https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/cross-building.md#generating-the-rootfs) in the runtime repo. You will need to clone the runtime [repo](https://github.com/dotnet/runtime.git) and build the appropriate "rootfs" for arm or arm64 using these instructions. You only need to do this once.
#### Ubuntu 14.04 ####
To release the latest tools:
-1) Merge all the commits for this release from the master branch to the release/stable branch.
+1) Merge all the commits for this release from the main branch to the release/stable branch.
2) Kick off an official build from the release/stable branch.
3) Change all the package version references in the documentation folder to this official build's package version to maintain the docs up to date.
4) Download the above packages from the successful official build under "Artifacts" -> "PackageArtifacts".
Debugging Linux or MacOS Core Dump
==================================
-These instructions will lead you through getting symbols, loading and debugging a Linux or MacOS core dump. The best way to generate a core dump on Linux (only) is through the [createdump](https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/xplat-minidump-generation.md#configurationpolicy) facility.
+These instructions will lead you through getting symbols, loading and debugging a Linux or MacOS core dump. The best way to generate a core dump on Linux (only) is through the [createdump](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/xplat-minidump-generation.md#configurationpolicy) facility.
Dumps created with gdb or gcore do not have all the managed state so various SOS or dotnet-dump commands may display "UNKNOWN" for type and function names. This can also happen with Linux system generated core dumps if the `coredump_filter` for the process is not set to at least 0x3f. See [core](http://man7.org/linux/man-pages/man5/core.5.html) for more information.
Because SOS now has symbol download support (both managed PDBs and native symbols via `loadsymbols`) all that lldb requires is the host program and a few other binaries. The host is usually `dotnet` but for self-contained applications it the .NET Core `apphost` renamed to the program/project name. These steps will handle either case and download the host lldb needs to properly diagnose a core dump. There are also cases that the runtime module (i.e. libcoreclr.so) is need by lldb.
-First install or update the dotnet CLI symbol tool. This only needs to be done once. See this [link](https://github.com/dotnet/symstore/tree/master/src/dotnet-symbol#install) for more details. We need version 1.0.142101 or greater of dotnet-symbol installed.
+First install or update the dotnet CLI symbol tool. This only needs to be done once. See this [link](https://github.com/dotnet/symstore/tree/main/src/dotnet-symbol#install) for more details. We need version 1.0.142101 or greater of dotnet-symbol installed.
~$ dotnet tool install -g dotnet-symbol
You can invoke the tool using the following command: dotnet-symbol
# Diagnostics Client Library API Design
## Intro
-The Diagnostics Client Library (currently named as "Runtime Client Library") - `Microsoft.Diagnostics.NetCore.Client.dll` - is a managed library that can be used to interact with the .NET runtime via the diagnostics IPC protocol as documented in https://github.com/dotnet/diagnostics/blob/master/documentation/design-docs/ipc-protocol.md. It provides managed classes for invoking the diagnostics IPC commands programmatically, and can be extended to write various diagnostics tools. It also comes with various classes that should facilitate interacting with the diagnostics IPC commands.
+The Diagnostics Client Library (currently named as "Runtime Client Library") - `Microsoft.Diagnostics.NetCore.Client.dll` - is a managed library that can be used to interact with the .NET runtime via the diagnostics IPC protocol as documented in https://github.com/dotnet/diagnostics/blob/main/documentation/design-docs/ipc-protocol.md. It provides managed classes for invoking the diagnostics IPC commands programmatically, and can be extended to write various diagnostics tools. It also comes with various classes that should facilitate interacting with the diagnostics IPC commands.
-The name "Diagnostics Client Library" comes from the fact that we call the runtime (CoreCLR) component responsible for accepting and handling the diagnostics IPC commands the "diagnostics server" - https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/diagnosticserver.h. Since this library is a managed library on the other side of the IPC protocol responsible for communicating with the runtime's "diagnostics server", calling this the "Diagnostics Client Library" made sense.
+The name "Diagnostics Client Library" comes from the fact that we call the runtime (CoreCLR) component responsible for accepting and handling the diagnostics IPC commands the "diagnostics server" - https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/diagnosticserver.h. Since this library is a managed library on the other side of the IPC protocol responsible for communicating with the runtime's "diagnostics server", calling this the "Diagnostics Client Library" made sense.
## Goals
## API Descriptions
-At a high level, the DiagnosticsClient class provides static methods that the user may call to invoke diagnostics IPC commands (i.e. start an EventPipe session, request a core dump, etc.) The library also provides several classes that may be helpful for invoking these commands. These commands are described in more detail in the diagnostics IPC protocol documentation available here: https://github.com/dotnet/diagnostics/blob/master/documentation/design-docs/ipc-protocol.md#commands.
+At a high level, the DiagnosticsClient class provides static methods that the user may call to invoke diagnostics IPC commands (i.e. start an EventPipe session, request a core dump, etc.) The library also provides several classes that may be helpful for invoking these commands. These commands are described in more detail in the diagnostics IPC protocol documentation available here: https://github.com/dotnet/diagnostics/blob/main/documentation/design-docs/ipc-protocol.md#commands.
### DiagnosticsClient
}
}
```
-
CPU Usage (%) 24
GC Heap Size (MB) 811
- 3. Monitoring EventCounter values from user-defined EventSource: (see https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Tracing/documentation/EventCounterTutorial.md on how to do this.0)
+ 3. Monitoring EventCounter values from user-defined EventSource: (see https://github.com/dotnet/corefx/blob/main/src/System.Diagnostics.Tracing/documentation/EventCounterTutorial.md on how to do this.0)
> dotnet-counters monitor --processId 1902 Samples-EventCounterDemos-Minimal
### Pprof
-Pprof is both a runtime library used by golang to collect trace data as well as a CLI tool to visualize that data after it has been collected. The CLI tool is the focus here. Snippets below from https://github.com/google/pprof/blob/master/doc/README.md
+Pprof is both a runtime library used by golang to collect trace data as well as a CLI tool to visualize that data after it has been collected. The CLI tool is the focus here. Snippets below from https://github.com/google/pprof/blob/main/doc/README.md
Pprof follows the convention Pprof <format\> [options] source.
This counter uses the [Monitor.LockContentionCount](https://docs.microsoft.com/en-us/dotnet/api/system.threading.monitor.lockcontentioncount?view=netcore-3.0) API to report the increment of the total lock contention count. The `DisplayRateTimeScale` property is an optional `TimeSpan` which can be set to provide a hint of what time interval this counter is best displayed at. For example, the lock contention count is best displayed as *count per second*, so its `DisplayRateTimeScale` is set to 1 second. This can be adjusted for different types of rate counters.
-There are more runtime counter implementation to use as a reference in the [CoreCLR](https://github.com/dotnet/runtime/blob/master/src/coreclr/src/System.Private.CoreLib/src/System/Diagnostics/Eventing/RuntimeEventSource.cs) repo.
+There are more runtime counter implementation to use as a reference in the [CoreCLR](https://github.com/dotnet/runtime/blob/main/src/coreclr/System.Private.CoreLib/src/System/Diagnostics/Eventing/RuntimeEventSource.cs) repo.
## Concurrency
It is important to note that if the delegates passed to the `PollingCounter`/`IncrementingPollingCounter` instances are called by multiple threads at once, the EventCounters API does not guarantee thread safety. It is the author's responsibility to guarantee the thread-safety of the delegates being passed to the counter APIs.
#### dotnet-counters
-dotnet-counters is a cross-platform dotnet CLI tool that can be used to monitor the counter values. To find out how to use `dotnet-counters` to monitor your counters, refer to the [dotnet-counters documentation](https://github.com/dotnet/diagnostics/blob/master/documentation/dotnet-counters-instructions.md).
+dotnet-counters is a cross-platform dotnet CLI tool that can be used to monitor the counter values. To find out how to use `dotnet-counters` to monitor your counters, refer to the [dotnet-counters documentation](https://github.com/dotnet/diagnostics/blob/main/documentation/dotnet-counters-instructions.md).
#### ETW/PerfView
dotnet-trace collect --process-id <pid> --providers Samples-EventCounterDemos-Minimal:0:0:EventCounterIntervalSec=1
```
-The official dotnet-trace documentation contains a [section](https://github.com/dotnet/diagnostics/blob/master/documentation/dotnet-trace-instructions.md#using-dotnet-trace-to-collect-counter-values-over-time) on how to do this in more detail.
+The official dotnet-trace documentation contains a [section](https://github.com/dotnet/diagnostics/blob/main/documentation/dotnet-trace-instructions.md#using-dotnet-trace-to-collect-counter-values-over-time) on how to do this in more detail.
#### TraceEvent
-TraceEvent is a managed library that makes it easy to consume ETW and EventPipe events. For more information, refer to the [TraceEvent Library Programmers Guide](https://github.com/Microsoft/perfview/blob/master/documentation/TraceEvent/TraceEventProgrammersGuide.md).
+TraceEvent is a managed library that makes it easy to consume ETW and EventPipe events. For more information, refer to the [TraceEvent Library Programmers Guide](https://github.com/Microsoft/perfview/blob/main/documentation/TraceEvent/TraceEventProgrammersGuide.md).
For some more detailed code samples, you can also try reading [Criteo Labs blog](https://medium.com/criteo-labs/net-core-counters-internals-how-to-integrate-counters-in-your-monitoring-pipeline-5354cd61b42e) on how to do this.
\ No newline at end of file
# .NET Core Diagnostics Vision
-[This document](https://github.com/dotnet/diagnostics/blob/master/documentation/diagnostics-planing.md)
+[This document](https://github.com/dotnet/diagnostics/blob/main/documentation/diagnostics-planing.md)
describes a high level vision/plan for diagnostics / monitoring for the .NET Core runtime.
The overarching goal is easy to state.
Then flesh that out with details on how to do specific investigations, and in particular all the
other work items listed here will be included in that documentation.
2. Add a new DumpASync command to the SOS debugging extension. Work with Visual Studio Team to have it integrated into their parallel stacks view. Make sure our existing Async diagnostics works well.
- 3. Create a new 'dotnet-collect' global command that allows the collection of EventPipe data 'by hand'. (See [dotnet-collect And dotnet-analyze](https://github.com/aspnet/AspLabs/tree/master/src/DotNetDiagnostics) for more.
+ 3. Create a new 'dotnet-collect' global command that allows the collection of EventPipe data 'by hand'. (See [dotnet-collect And dotnet-analyze](https://github.com/aspnet/AspLabs/tree/main/src/DotNetDiagnostics) for more.
It should be able to collect traces that can be read with either PerfView or Visual Studio.
4. Create a new 'dotnet-analyze' global command that allows you to do investigations on crash dumps. Simple triage of crashes as well as memory investigations should be possible.
5. Insure that normal Azure and App-Insights default dashboard metrics work with .NET Core (on all platforms). dotnet-collect will allow the ad-hoc collection of metrics for local monitoring.
GC Heap Size (MB) 811
Number of Exceptions / sec 4
- 3. Monitoring EventCounter values from user-defined EventSource: (see https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Tracing/documentation/EventCounterTutorial.md on how to do this.0)
+ 3. Monitoring EventCounter values from user-defined EventSource: (see https://github.com/dotnet/corefx/blob/main/src/System.Diagnostics.Tracing/documentation/EventCounterTutorial.md on how to do this.0)
> dotnet-counters monitor --process-id 1902 Samples-EventCounterDemos-Minimal
## Using dotnet-dump
-The next step is to collect a dump. This can be skipped if a core dump has already been generated by the operating system or [createdump](https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/xplat-minidump-generation.md#configurationpolicy) on Linux. The default dump type (--type option) is currently "full".
+The next step is to collect a dump. This can be skipped if a core dump has already been generated by the operating system or [createdump](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/xplat-minidump-generation.md#configurationpolicy) on Linux. The default dump type (--type option) is currently "full".
On Linux, the .NET runtime version must be 3.0 or greater. On Windows, `dotnet-dump collect` will work with any version of the .NET runtime.
Codesymbols | 400000000 | Events that will dump PDBs of dynamically generated assemblies to the EventPipe stream.
Default | 4C14FCCBD | Recommend default flags (good compromise on verbosity).
-[source](https://github.com/Microsoft/perfview/blob/master/src/TraceEvent/Parsers/ClrTraceEventParser.cs#L41)
+[source](https://github.com/Microsoft/perfview/blob/main/src/TraceEvent/Parsers/ClrTraceEventParser.cs#L41)
## More information on .NET Providers
Here are some instructions on how to run the diagnostics repo's tests against a locally build private .NET Core runtime. These directions will work on Windows, Linux and MacOS.
-1. Build the runtime repo (see [Workflow Guide](https://github.com/dotnet/runtime/blob/master/docs/workflow/README.md)).
+1. Build the runtime repo (see [Workflow Guide](https://github.com/dotnet/runtime/blob/main/docs/workflow/README.md)).
2. Build the diagnostics repo (see [Building the Repository](../README.md)).
3. Run the diagnostics repo tests with the -privatebuildpath option.
```
~/diagnostics$ ./test.sh --privatebuildpath /home/user/runtime/artifacts/bin/coreclr/Linux.x64.Debug
```
-The private runtime will be copied to the diagnostics repo and the tests started. It can be just the runtime binaries but this assumes that the private build is close to the latest published master build. If not, you can pass the runtime's testhost directory containing all the shared runtime bits i.e. `c:\runtime\artifacts\bin\coreclr\testhost\netcoreapp5.0-Windows_NT-Debug-x64\shared\Microsoft.NETCore.App\5.0.0` or `/home/user/runtime/artifacts/bin/coreclr/testhost/netcoreapp5.0-Linux-Release-x64/shared/Microsoft.NETCore.App/5.0.0`
+The private runtime will be copied to the diagnostics repo and the tests started. It can be just the runtime binaries but this assumes that the private build is close to the latest published main build. If not, you can pass the runtime's testhost directory containing all the shared runtime bits i.e. `c:\runtime\artifacts\bin\coreclr\testhost\netcoreapp5.0-Windows_NT-Debug-x64\shared\Microsoft.NETCore.App\5.0.0` or `/home/user/runtime/artifacts/bin/coreclr/testhost/netcoreapp5.0-Linux-Release-x64/shared/Microsoft.NETCore.App/5.0.0`
On Linux/MacOS it is recommended to test against Release runtime builds because of a benign assert in DAC (tracked by issue #[31897](https://github.com/dotnet/runtime/issues/31897)) that causes the tests to fail.
In both cases, you have to be careful to roughly match the environment up with the production server. For example, if I am running .net core preview 5 on Ubuntu 16.04 the core dump must be analyzed on the same architecture and environment.
-For the LLDB/SOS experience, please see - https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/debugging-instructions.md.
+For the LLDB/SOS experience, please see - https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/debugging-instructions.md.
To use the dotnet-dump tool to analyze the dump please run:
Before we get started, you need to do the following:
1. Clone the dotnet/diagnostics repo (https://github.com/dotnet/diagnostics)
-2. Make sure all the pre-requisites are in place to build the repo (https://github.com/dotnet/diagnostics/blob/master/README.md)
+2. Make sure all the pre-requisites are in place to build the repo (https://github.com/dotnet/diagnostics/blob/main/README.md)
3. Add the uniquestacks.cs file to ~/diagnostics/src/Tools/dotnet-dump/Commands folder.
4. Build the repo using ~/diagnostics/build.sh
This document is written for people who need to use the bleeding edge SOS freshly built from the enlistment. You may need to do it because you want the latest feature, or you are developing your own SOS command and you want to try it out. Regardless of the reason, here is how you can do it.
-Before we can use the private build, of course, we must build it first. [Here](https://github.com/dotnet/diagnostics/tree/master/documentation/building) is the documentation on how to do that.
+Before we can use the private build, of course, we must build it first. [Here](https://github.com/dotnet/diagnostics/tree/main/documentation/building) is the documentation on how to do that.
## Windows
```
Then we are using our own sos and we can do whatever we want with it!
-
SET (CMAKE_C_FLAGS_DEBUG_INIT "-g -O0")
SET (CLR_C_FLAGS_CHECKED_INIT "-g -O1")
# Refer to the below instruction to support __thread with -O2/-O3 on Linux/ARM
-# https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/linux-instructions.md
+# https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/linux-instructions.md
SET (CMAKE_C_FLAGS_RELEASE_INIT "-g -O1")
SET (CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "-g -O1")
SET (CMAKE_C_FLAGS_DEBUG_INIT "-g -O0")
SET (CLR_C_FLAGS_CHECKED_INIT "-g -O2")
# Refer to the below instruction to support __thread with -O2/-O3 on Linux/ARM
-# https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/linux-instructions.md
+# https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/linux-instructions.md
SET (CMAKE_C_FLAGS_RELEASE_INIT "-g -O3")
SET (CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "-g -O2")
:call_vs
if not exist "%_VSCOMNTOOLS%" (
echo %__MsgPrefix%Error: Visual Studio 2017 or 2019 required.
- echo Please see https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/windows-instructions.md for build instructions.
+ echo Please see https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/windows-instructions.md for build instructions.
exit /b 1
)
echo %__MsgPrefix%"%_VSCOMNTOOLS%\VsDevCmd.bat"
return tks.ToString();
}
- // from CLR implementation in https://github.com/dotnet/runtime/blob/master/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs#L141
+ // from CLR implementation in https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs#L141
internal const int TASK_STATE_STARTED = 0x00010000;
internal const int TASK_STATE_DELEGATE_INVOKED = 0x00020000;
internal const int TASK_STATE_DISPOSED = 0x00040000;
// Store character literals as it iterates the command line. Escaped
// characters within double quotes are unescaped for non-Windows systems.
// Algorithm based on INIT_FormatCommandLine behavior from
- // https://github.com/dotnet/runtime/blob/master/src/coreclr/src/pal/src/init/pal.cpp
+ // https://github.com/dotnet/runtime/blob/main/src/coreclr/pal/src/init/pal.cpp
StringBuilder builder = new StringBuilder(commandLineLength);
do
{
private void ReadPortableDebugTableEntries(PEReader peReader, out DebugDirectoryEntry codeViewEntry, out DebugDirectoryEntry embeddedPdbEntry)
{
- // See spec: https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PE-COFF.md
+ // See spec: https://github.com/dotnet/runtime/blob/main/docs/design/specs/PE-COFF.md
codeViewEntry = default;
embeddedPdbEntry = default;
};
// This struct needs to match the definition in the runtime.
-// See: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/clrex.h
+// See: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/clrex.h
struct StackTraceElement
{
UINT_PTR ip;
if (arrayLen != 0 && hr == S_OK)
{
// This code is accessing the StackTraceInfo class in the runtime.
- // See: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/clrex.h
+ // See: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/clrex.h
#ifdef _TARGET_WIN64_
DWORD_PTR dataPtr = taStackTrace + sizeof(DWORD_PTR) + sizeof(DWORD) + sizeof(DWORD);
#else
if (arrayLen)
{
// This code is accessing the StackTraceInfo class in the runtime.
- // See: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/clrex.h
+ // See: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/clrex.h
#ifdef _TARGET_WIN64_
DWORD_PTR dataPtr = arrayPtr + sizeof(DWORD_PTR) + sizeof(DWORD) + sizeof(DWORD);
#else
//
// Note: This file gets parsed by the Mono IL Linker (https://github.com/mono/linker/) which may throw an exception during parsing.
-// Specifically, this (https://github.com/mono/linker/blob/master/corebuild/integration/ILLink.Tasks/CreateRuntimeRootDescriptorFile.cs) will try to
+// Specifically, this (https://github.com/mono/linker/blob/main/src/ILLink.Tasks/CreateRuntimeRootDescriptorFile.cs) will try to
// parse this header, and it may throw an exception while doing that. If you edit this file and get a build failure on msbuild.exe D:\repos\coreclr\build.proj
// you might want to check out the parser linked above.
//
// ******************************************************************************
// WARNING!!!: This code is also used by the runtime repo.
-// See: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/inc/gcdecoder.cpp
+// See: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/gcdecoder.cpp
// ******************************************************************************
#ifdef _TARGET_X86_
// ******************************************************************************
// WARNING!!!: This header is also used by the runtime repo.
-// See: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/inc/gcdump.h
+// See: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/gcdump.h
// ******************************************************************************
/*****************************************************************************/
// ******************************************************************************
// WARNING!!!: This header is also used by the runtime repo.
-// See: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/inc/gcinfo.h
+// See: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/gcinfo.h
// ******************************************************************************
/*****************************************************************************/
// ******************************************************************************
// WARNING!!!: This header is also used by the runtime repo.
-// See: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/inc/gcinfodecoder.h
+// See: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/gcinfodecoder.h
// ******************************************************************************
#ifndef _GC_INFO_DECODER_
#endif // _GC_INFO_DECODER_
-
// ******************************************************************************
// WARNING!!!: This header is also used by the runtime repo.
-// See: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/inc/gcinfodumper.h
+// See: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/gcinfodumper.h
// ******************************************************************************
//
#endif // !__GCINFODUMPER_H__
-
// ******************************************************************************
// WARNING!!!: This header is also used by the runtime repo.
-// See: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/inc/gcinfotypes.h
+// See: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/gcinfotypes.h
// ******************************************************************************
#define PARTIALLY_INTERRUPTIBLE_GC_SUPPORTED
#endif
#endif // !__GCINFOTYPES_H__
-
// ******************************************************************************
// WARNING!!!: This header is subset of
-// https://github.com/dotnet/runtime/blob/master/src/coreclr/src/inc/predeftlsslot.h
+// https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/predeftlsslot.h
// that SOS depends on.
// ******************************************************************************
// ******************************************************************************
// WARNING!!!: This header is also used by the runtime repo.
-// See: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/inc/stresslog.h
-// Parser: https://github.com/dotnet/diagnostics/blob/master/src/SOS/Strike/stressLogDump.cpp
+// See: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/stresslog.h
+// Parser: https://github.com/dotnet/diagnostics/blob/main/src/SOS/Strike/stressLogDump.cpp
// ******************************************************************************
#define ALLOW_SXS_JIT
#define ALLOW_SXS_JIT_NGEN
-//master switch for gc suspension not based on hijacking
+//main switch for gc suspension not based on hijacking
#define FEATURE_ENABLE_GCPOLL
#if defined(_TARGET_X86_)
// ******************************************************************************
// WARNING!!!: This header is also used by the runtime repo.
-// See: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/inc/tls.h
+// See: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/tls.h
// ******************************************************************************
#ifndef __tls_h__
/* File created by MIDL compiler version 8.01.0622 */
/* at Mon Jan 18 19:14:07 2038
*/
-/* Compiler settings for C:/ssd/runtime/src/coreclr/src/inc/clrdata.idl:
+/* Compiler settings for C:/ssd/runtime/src/coreclr/inc/clrdata.idl:
Oicf, W1, Zp8, env=Win32 (32b run), target_arch=X86 8.01.0622
protocol : dce , ms_ext, c_ext, robust
error checks: allocation ref bounds_check enum stub_data
#ifdef __cplusplus
}
#endif
-
-
-
/* File created by MIDL compiler version 8.01.0622 */
/* at Mon Jan 18 19:14:07 2038
*/
-/* Compiler settings for C:/ssd/runtime/src/coreclr/src/inc/sospriv.idl:
+/* Compiler settings for C:/ssd/runtime/src/coreclr/inc/sospriv.idl:
Oicf, W1, Zp8, env=Win32 (32b run), target_arch=X86 8.01.0622
protocol : dce , ms_ext, c_ext, robust
error checks: allocation ref bounds_check enum stub_data
#ifdef __cplusplus
}
#endif
-
-
-
/* File created by MIDL compiler version 8.01.0622 */
/* at Mon Jan 18 19:14:07 2038
*/
-/* Compiler settings for C:/ssd/runtime/src/coreclr/src/inc/clrdata.idl:
+/* Compiler settings for C:/ssd/runtime/src/coreclr/inc/clrdata.idl:
Oicf, W1, Zp8, env=Win32 (32b run), target_arch=X86 8.01.0622
protocol : dce , ms_ext, c_ext, robust
error checks: allocation ref bounds_check enum stub_data
#endif
#endif
-
-
output, because those functions do tracing and we need to avoid recursion */
extern FILE *output_file;
-/* master switch for debug channel enablement, to be modified by debugger */
+/* main switch for debug channel enablement, to be modified by debugger */
extern Volatile<BOOL> dbg_master_switch ;
#endif // __cplusplus
#endif /* _PAL_DBGMSG_H_ */
-
-
output, because those functions do tracing and we need to avoid recursion */
FILE *output_file = NULL;
-/* master switch for debug channel enablement, to be modified by debugger */
+/* main switch for debug channel enablement, to be modified by debugger */
Volatile<BOOL> dbg_master_switch = TRUE;
//
// Sample lines:
//
-// <1><0x9ad2 GOFF=0x1e17b22><DW_TAG_structure_type> DW_AT_name<"STORAGESIGNATURE"> DW_AT_byte_size<0x00000010> DW_AT_decl_file<0x00000014 /home/stmaclea/git/runtime/src/coreclr/src/md/inc/mdfileformat.h> DW_AT_decl_line<0x0000003f>
-// <1><0x44 GOFF=0x1b51><DW_TAG_structure_type> DW_AT_name<"_GUID"> DW_AT_byte_size<0x00000010> DW_AT_decl_file<0x00000001 /home/stmaclea/git/runtime/src/coreclr/src/pal/inc/pal_mstypes.h> DW_AT_decl_line<0x000002ab>
-// <2><0x4d GOFF=0x1b5a><DW_TAG_member> DW_AT_name<"Data1"> DW_AT_type<<0x00000082 GOFF=0x00001b8f>> DW_AT_decl_file<0x00000001 /home/stmaclea/git/runtime/src/coreclr/src/pal/inc/pal_mstypes.h> DW_AT_decl_line<0x000002ac> DW_AT_data_member_location<0>
+// <1><0x9ad2 GOFF=0x1e17b22><DW_TAG_structure_type> DW_AT_name<"STORAGESIGNATURE"> DW_AT_byte_size<0x00000010> DW_AT_decl_file<0x00000014 /home/stmaclea/git/runtime/src/coreclr/md/inc/mdfileformat.h> DW_AT_decl_line<0x0000003f>
+// <1><0x44 GOFF=0x1b51><DW_TAG_structure_type> DW_AT_name<"_GUID"> DW_AT_byte_size<0x00000010> DW_AT_decl_file<0x00000001 /home/stmaclea/git/runtime/src/coreclr/pal/inc/pal_mstypes.h> DW_AT_decl_line<0x000002ab>
+// <2><0x4d GOFF=0x1b5a><DW_TAG_member> DW_AT_name<"Data1"> DW_AT_type<<0x00000082 GOFF=0x00001b8f>> DW_AT_decl_file<0x00000001 /home/stmaclea/git/runtime/src/coreclr/pal/inc/pal_mstypes.h> DW_AT_decl_line<0x000002ac> DW_AT_data_member_location<0>
using System.Collections.Generic;
using System.Globalization;
class DwarfParser
{
static Regex typeNameRegEx = new Regex(@"^<(?<nesting>\d+)><.*GOFF=0x(?<goff>[0-9a-fA-F]+)><DW_TAG_((class_type)|(structure_type)|(union_type)|(typedef))>(.*DW_AT_name<(?<name>[^<>]*(((?'Open'<)[^<>]*)+((?'Close-Open'>)[^<>]*)+)*(?(Open)(?!)))>)?");
- // <1><0x9ad2 GOFF=0x1e17b22><DW_TAG_structure_type> DW_AT_name<STORAGESIGNATURE> DW_AT_byte_size<0x00000010> DW_AT_decl_file<0x00000014 /home/stmaclea/git/runtime/src/coreclr/src/md/inc/mdfileformat.h> DW_AT_decl_line<0x0000003f>
+ // <1><0x9ad2 GOFF=0x1e17b22><DW_TAG_structure_type> DW_AT_name<STORAGESIGNATURE> DW_AT_byte_size<0x00000010> DW_AT_decl_file<0x00000014 /home/stmaclea/git/runtime/src/coreclr/md/inc/mdfileformat.h> DW_AT_decl_line<0x0000003f>
static Regex typeRegEx = new Regex(@"^<(?<nesting>\d+)><.*GOFF=0x(?<goff>[0-9a-fA-F]+)><DW_TAG_((class)|(structure)|(union))_type>(.*DW_AT_name<(?<name>[^<>]*(((?'Open'<)[^<>]*)+((?'Close-Open'>)[^<>]*)+)*(?(Open)(?!)))>)?.*?DW_AT_decl_file");
- // <2><0x4d GOFF=0x1b5a><DW_TAG_member> DW_AT_name<Data1> DW_AT_type<<0x00000082 GOFF=0x00001b8f>> DW_AT_decl_file<0x00000001 /home/stmaclea/git/runtime/src/coreclr/src/pal/inc/pal_mstypes.h> DW_AT_decl_line<0x000002ac> DW_AT_data_member_location<0>
+ // <2><0x4d GOFF=0x1b5a><DW_TAG_member> DW_AT_name<Data1> DW_AT_type<<0x00000082 GOFF=0x00001b8f>> DW_AT_decl_file<0x00000001 /home/stmaclea/git/runtime/src/coreclr/pal/inc/pal_mstypes.h> DW_AT_decl_line<0x000002ac> DW_AT_data_member_location<0>
static Regex memberRegEx = new Regex(@"^<(?<nesting>\d+)><.*GOFF=0x(?<goff>[0-9a-fA-F]+)><DW_TAG_member>.*.*?DW_AT_data_member_location<(?<offset>\d+) *([(][^)]*[)])?>");
// DW_AT_name<Data1>
projects / platform / core / dotnet / diagnostics.git / commitdiff