netcoredbg is an open source, cross-platform .NET debugger led by Samsung. It addresses the long-standing lack of an auditable debugging backend in the free software ecosystem. It supports GDB/MI, DAP, and CLI, and now includes merged LoongArch64 support, completing the .NET debugging path on domestic CPU architectures. Keywords: netcoredbg, LoongArch64, .NET debugging.
Technical Specifications Show the Project Footprint
| Parameter | Description |
|---|---|
| Project Name | netcoredbg |
| Implementation Language | C++ |
| Open Source License | MIT |
| Debugging Protocols | GDB/MI, VSCode DAP, CLI |
| Supported Operating Systems | Linux, macOS, Windows |
| Supported Architectures | ARM, ARM64, x86, x64, RISC-V64, LoongArch64 |
| Upstream Maintainer | Samsung Electronics |
| Core Dependencies | CoreCLR, dbgshim/libdbgshim.so, CMake, Clang |
| Repository | github.com/Samsung/netcoredbg |
netcoredbg Has Become Critical Infrastructure for Open .NET Debugging
The core value of netcoredbg is not simply that it can debug .NET applications. More importantly, it fills a long-standing gap in the .NET ecosystem by providing a free, open source debugger under cross-platform assumptions. Compared with vsdbg, which depends on proprietary distribution, netcoredbg allows teams to build, audit, distribute, and tailor the full debugging stack themselves.
This matters especially for Linux distribution maintainers, domestic computing platform builders, and regulated industries that require supply chain control. When the runtime is open source but the debugger is proprietary, the developer experience is fundamentally constrained. netcoredbg brings .NET closer to a complete ecosystem on emerging architectures instead of stopping at merely “it runs.”
It Covers Both Traditional and Modern Development Environments Through Three Interfaces
The project supports GDB/MI, VSCode DAP, and a native CLI at the same time. This is not feature sprawl. It abstracts the debugging backend into a reusable capability layer: traditional IDEs can use MI, modern editors can use DAP, and automation workflows can invoke the CLI directly.
# Start DAP mode for frontends such as VSCode and VSCodium
netcoredbg --interpreter=vscode
# Start CLI mode for terminals and automation scripts
netcoredbg --interpreter=cli
# Attach to a running process, commonly used for production issue diagnosis
netcoredbg --attach 12345These commands show the three typical entry points for netcoredbg: IDE integration, terminal debugging, and process attachment.
netcoredbg Builds Its Technical Architecture on Top of CoreCLR Debugging Interfaces
Its low-level capabilities come from the CoreCLR debugging API and dbgshim. The former exposes managed debugging semantics, while the latter discovers the runtime, establishes the communication channel, and loads the matching version of the debugging interface library. For that reason, version matching is not an optimization detail. It is a prerequisite for successful debugging.
If the target application runs on .NET 8, the dbgshim major version must match it. Otherwise, common outcomes include empty call stacks, invisible variables, or direct interface errors. This is also the root cause behind many cases where an application “starts but cannot be debugged.”
LoongArch64 Support Has Already Entered the Mainline Build Configuration
The key LoongArch64 milestone is that the upstream main branch now includes architecture detection and macro definition logic. The significance is not just that it can “recognize a new CPU.” It also opens the compilation path for future platform-specific code, register access, and runtime compatibility work.
elseif(CLR_CMAKE_PLATFORM_ARCH_LOONGARCH64)
add_definitions(-D_LOONGARCH64_) # Base architecture identifier for LoongArch64
add_definitions(-DLOONGARCH64) # Simplified architecture macro for legacy code compatibility
add_definitions(-D_WIN64) # Reuse common macros for 64-bit platforms
add_definitions(-DBIT64=1) # Numeric bit-width marker
add_definitions(-DHOST_64BIT=1) # Compatibility with older CoreCLR versions
add_definitions(-DHOST_LOONGARCH64) # Host architecture macro for newer CoreCLR versions
endif()This configuration shows that netcoredbg has already brought LoongArch64 into the official compile-time architecture branches rather than leaving it as an external patch.
LoongArch64 Support Matters Because It Completes the .NET Debugging Loop on Domestic Architectures
The LoongArch community pushed netcoredbg adaptation for one fundamental reason: the .NET Runtime has gradually become runnable on the platform, but without a usable debugger, the developer experience remains incomplete. Without a debugger, IDE integration, breakpoint inspection, variable evaluation, and production diagnostics all become limited.
According to publicly available information, LoongArch64 support was advanced jointly by community contributors and Samsung maintainers, with the key commit identified as 577d7e5. That means the feature no longer depends on local private patches. It has entered the official maintenance path and future release evolution.
Upstream Merge Changes More Than Just Adding One Item to a Support List
Once a feature enters the mainline branch, LoongArch64 gains the benefits of continuous integration, future version adaptation, documentation synchronization, and issue tracking. For distributions, internal enterprise toolchains, and IDE plugin developers, this significantly reduces maintenance cost.
At the same time, the README now lists LoongArch64 as an officially supported architecture alongside ARM64, x64, and RISC-V64. This sends a clear signal: domestic CPU architectures have entered the formal compatibility matrix of the .NET debugging infrastructure.
Ecosystem Integration Determines Real-World Adoption of netcoredbg
In desktop development, the most important deployment model for netcoredbg is as the debugging backend for VSCodium- or VSCode-compatible frontends. DAP support allows it to plug into standardized editor workflows without binding users to a single IDE ecosystem.
At the Linux distribution level, packaging support through channels such as Arch AUR, Gentoo Portage, and NixOS also shows that netcoredbg is no longer a niche tool that only works when built from source. It has entered a software supply system that supports distribution and operations.
A Minimal launch Configuration Is Enough for Everyday Debugging
{
"version": "0.2.0",
"configurations": [
{
"name": ".NET with netcoredbg",
"type": "coreclr",
"request": "launch",
"program": "${workspaceFolder}/bin/Debug/net8.0/App.dll",
"cwd": "${workspaceFolder}",
"stopAtEntry": false
}
]
}The purpose of this configuration is to bind a standard DAP frontend and the netcoredbg backend into the same debugging session.
The Current Conclusion Is That LoongArch64 Moves netcoredbg from Cross-Platform to Cross-Ecosystem
x64, ARM64, and RISC-V64 already demonstrate the general architectural flexibility of netcoredbg. The addition of LoongArch64 shows that the project can also respond to the practical needs of regional and sovereign hardware ecosystems. This is not just another architecture port. It is a structural entry point for open source toolchains into new markets.
For developers, the most important point is not the commit itself but the three resulting facts: the official mainline has accepted the feature, the documentation now confirms support, and the ecosystem integration path is clear. From this point forward, the variables that most affect real-world experience are runtime binary availability, dbgshim compatibility, and the maturity of distribution packaging.
FAQ: The Three Questions Developers Care About Most
1. What is the fundamental difference between netcoredbg and vsdbg?
netcoredbg is an MIT-licensed open source debugger that users can build and distribute themselves. vsdbg is primarily distributed as proprietary software. netcoredbg is therefore a better fit for free software ecosystems, domestic computing platforms, and environments that require an auditable supply chain.
2. Is LoongArch64 already usable, or does it only compile?
Based on public information, LoongArch64 has already entered the upstream mainline and has been added to the official support list, which means it is no longer just an experimental external patch. However, the actual experience still depends on whether the corresponding .NET Runtime, dbgshim, and distribution packaging are all mature and aligned.
3. What is the most common pitfall when deploying netcoredbg on LoongArch platforms?
The most common issue is a version mismatch between dbgshim and the target runtime. The second is an incomplete native build environment, such as missing the correct versions of Clang, CMake, or the LoongArch-specific .NET SDK/Runtime.
Core Summary Clarifies the Key Technical and Ecosystem Takeaways
This article reconstructs the technical trajectory of netcoredbg, focusing on its protocol support as an open source cross-platform .NET debugger, its runtime dependencies, its six-architecture support matrix, and the key progress that moved LoongArch64 support from a community patch to an upstream Samsung-maintained feature. The goal is to help developers quickly understand both its ecosystem value and its practical adoption path.