[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-6373":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":23,"hasPages":23,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":26,"readmeContent":27,"aiSummary":28,"trendingCount":16,"starSnapshotCount":16,"syncStatus":29,"lastSyncTime":30,"discoverSource":31},6373,"raddebugger","EpicGamesExt\u002Fraddebugger","EpicGamesExt","A native, user-mode, multi-process, graphical debugger.","",null,"C",7036,318,59,200,0,1,16,113,8,83.51,"MIT License",false,"master",[],"2026-06-12 04:00:28","# The RAD Debugger Project\r\n\r\n_**NOTE:** This README does not document usage instructions and tips for the\r\ndebugger itself, and is intended as a technical overview of the project. The\r\ndebugger's README, which includes usage instructions and tips, can be found\r\npackaged along with debugger releases, or within the `build` folder after a\r\nlocal copy has been built. You can find pre-built release binaries\r\n[here](https:\u002F\u002Fgithub.com\u002FEpicGamesExt\u002Fraddebugger\u002Freleases)._\r\n\r\nThe RAD Debugger is a native, user-mode, multi-process, graphical debugger. It\r\ncurrently only supports local-machine Windows x64 debugging with PDBs, with\r\nplans to expand and port in the future. In the future we'll expand to also\r\nsupport native Linux debugging and DWARF debug info.\r\n\r\nThe debugger is currently in *ALPHA*. In order to get the debugger\r\nbullet-proof, it'd greatly help out if you submitted the issues you find\r\n[here](https:\u002F\u002Fgithub.com\u002FEpicGamesExt\u002Fraddebugger\u002Fissues), along with any\r\ninformation you can gather, like dump files (along with the build you used),\r\ninstructions to reproduce, test executables, and so on.\r\n\r\nIn addition to the debugger, we aim to further improve the toolchain with two\r\nadditional related technologies: **(1)** the RAD Debug Info (RDI) format, and\r\n**(2)** the RAD Linker.\r\n\r\n## The RAD Debug Info (RDI) Format\r\n\r\nThe RAD Debug Info (RDI) format is our custom debug information format, which\r\nthe debugger parses and uses, rather than the debug information natively\r\nproduced by toolchains, like PDB or DWARF. To work with these existing\r\ntoolchains, we convert PDB (and eventually PE\u002FELF files with embedded DWARF)\r\ninto the RDI format on-demand.\r\n\r\nThe RDI format is currently specified in code, in the files within the\r\n`src\u002Flib_rdi` folder. In [`rdi.h`](src\u002Flib_rdi\u002Frdi.h) and\r\n[`rdi.c`](src\u002Flib_rdi\u002Frdi.c), the types and functions which define the format\r\nitself are specified. In [`rdi_parse.h`](src\u002Flib_rdi\u002Frdi_parse.h) and\r\n[`rdi_parse.c`](src\u002Flib_rdi\u002Frdi_parse.c), helpers for parsing the format are\r\nincluded.\r\n\r\nWe also have an in-progress library for constructing and serializing RDI data,\r\nlocated within the `src\u002Flib_rdi_make` folder.\r\n\r\nOur `radbin` utility (accessible through the debugger too, via the `--bin`\r\ncommand line argument) is capable of converting native debug information formats\r\nto RDI, and of producing textual dumps of contents stored within RDI files.\r\n\r\n## The RAD Linker\r\n\r\nThe RAD Linker is a new performance linker for generating x64 PE\u002FCOFF binaries.\r\nIt is designed to be very fast when creating gigantic executables. It generates\r\nstandard PDB files for debugging, but it can also (optionally) natively create\r\nRAD Debug Info too, which is useful both to eliminate on-demand conversion time\r\nwhen debugging, but also for huge executables that otherwise create broken\r\nPDBs that overflow internal 32-bit tables.\r\n\r\nThe RAD Linker is primarily optimized to handle huge linking projects. In our\r\ntest cases (where debug info is multiple gigabytes), we see 50% faster link\r\ntimes.\r\n\r\nThe command line syntax is fully compatible with MSVC; you can get a full list\r\nof implemented switches from `\u002Fhelp`.\r\n\r\nOur current designed-for use case for the linker is to help with the\r\ncompile-debug cycle of huge projects. We don't yet have support for\r\nlink-time-optimizations, but this feature is on the road map.\r\n\r\nBy default, the linker spawns as many threads as there are cores, so if you plan\r\nto run multiple linkers in parallel, you can limit the number of thread workers\r\nvia `\u002Frad_workers`.\r\n\r\nWe also have support for large memory pages, which, when enabled, reduce link\r\ntime by another 25%. To link with large pages, you need to explicitly request\r\nthem via `\u002Frad_large_pages`. Large pages are off by default, since Windows\r\nsupport for large pages is a bit buggy; we recommend they only be used in Docker\r\nor VM images where the environment is reset after each link. In a standard\r\nWindows environment, using large pages otherwise will fragment memory quickly,\r\nforcing a reboot. We are working on a Linux port of the linker that will be able\r\nto build with large pages robustly.\r\n\r\nA benchmark of the linker's performance is below:\r\n\r\n![AMD Ryzen Threadripper PRO 3995WX 64-Cores, 256 GiB RAM (Windows x64)](https:\u002F\u002Fgithub.com\u002Fuser-attachments\u002Fassets\u002Fa95b382a-76b4-4a4c-b809-b61fe25e667a)\r\n\r\n---\r\n\r\n# Project Development Setup Instructions\r\n\r\n**NOTE: Currently, only x64 Windows development is supported for the project.**\r\n\r\n## 1. Installing the Required Tools (MSVC & Windows SDK)\r\n\r\nIn order to work with the codebase, you'll need the [Microsoft C\u002FC++ Build Tools\r\nv15 (2017) or later](https:\u002F\u002Faka.ms\u002Fvs\u002F17\u002Frelease\u002Fvs_BuildTools.exe), for both\r\nthe Windows SDK and the MSVC compiler and linker.\r\n\r\nIf the Windows SDK is installed (e.g. via installation of the Microsoft C\u002FC++\r\nBuild Tools), you may also build with [Clang](https:\u002F\u002Freleases.llvm.org\u002F).\r\n\r\n## 2. Build Environment Setup\r\n\r\nBuilding the codebase can be done in a terminal which is equipped with the\r\nability to call either MSVC or Clang from command line.\r\n\r\nThis is generally done by calling `vcvarsall.bat x64`, which is included in the\r\nMicrosoft C\u002FC++ Build Tools. This script is automatically called by the `x64\r\nNative Tools Command Prompt for VS \u003Cyear>` variant of the vanilla `cmd.exe`. If\r\nyou've installed the build tools, this command prompt may be easily located by\r\nsearching for `Native` from the Windows Start Menu search.\r\n\r\nYou can ensure that the MSVC compiler is accessible from your command line by\r\nrunning:\r\n\r\n```\r\ncl\r\n```\r\n\r\nIf everything is set up correctly, you should have output very similar to the\r\nfollowing:\r\n\r\n```\r\nMicrosoft (R) C\u002FC++ Optimizing Compiler Version 19.29.30151 for x64\r\nCopyright (C) Microsoft Corporation.  All rights reserved.\r\n\r\nusage: cl [ option... ] filename... [ \u002Flink linkoption... ]\r\n```\r\n\r\n### 3. Building\r\n\r\nWithin this terminal, `cd` to the root directory of the codebase, and just run\r\nthe `build.bat` script:\r\n\r\n```\r\nbuild\r\n```\r\n\r\nYou should see the following output:\r\n\r\n```\r\n[debug mode]\r\n[msvc compile]\r\n[default mode, assuming `raddbg` build]\r\nmetagen_main.c\r\nsearching C:\\devel\\raddebugger\u002Fsrc... 458 files found\r\nparsing metadesk... 16 metadesk files parsed\r\ngathering tables... 97 tables found\r\ngenerating layer code...\r\nraddbg_main.c\r\n```\r\n\r\nIf everything worked correctly, there will be a `build` folder in the root\r\nlevel of the codebase, and it will contain a freshly-built `raddbg.exe`.\r\n\r\nThis `raddbg.exe` will have been built in **debug mode**, which is not built\r\nwith optimizations, and may perform worse. To produce a\r\n**release mode executable**, run `build.bat` with a `release` argument:\r\n\r\n```\r\nbuild release\r\n```\r\n\r\nThis build will take significantly longer.\r\n\r\nBy default, `build.bat` only builds the debugger if no arguments (or just\r\n`release`) are passed, but additional arguments can be passed to build the RAD\r\nLinker, or the `radbin` CLI binary file utility:\r\n\r\n```\r\nbuild radlink release\r\nbuild radbin release\r\n```\r\n\r\n---\r\n\r\n# Project Roadmap\r\n\r\n### The Initial Alpha Battle-Testing Phase\r\n\r\nThe first priority for the project is to ensure that the most crucial components\r\nare functioning extremely reliably for local, x64, Windows development.\r\nFor the debugger, this would include parts like debug info conversion, debug\r\ninfo loading, process control, stepping, evaluation (correct usage of both\r\nlocation info and type info), and a robust frontend which ensures the lower\r\nlevel parts are usable. For the linker, this is a matter of reliability and\r\nconvergence with existing linker behavior.\r\n\r\nWe feel that we've already come a long way in all of these respects, but given\r\nthe massive set of possible combinations of languages, build settings,\r\ntoolchains, used language features, and patterns of generated code, we still\r\nexpect some issues, and are prioritizing these issues being resolved first.\r\n\r\nWe also hope to continue to improve performance in this phase. For the debugger,\r\nthis primarily includes frontend performance, introducing caches when economical\r\nto do so, and tightening existing systems up. For the linker, it has been mostly\r\ntuned thus far for giant projects, and so we'd like to improve linking speed for\r\nsmall-to-mid sized projects as well.\r\n\r\nFor the linker, there are also a number of features to come, like\r\ndead-code-elimination (`\u002Fopt:ref`), and link-time-optimizations with the help\r\nof `clang` (we won't support LTCG from MSVC, since it is undocumented).\r\n\r\n### Local x64 Linux Debugging Phase\r\n\r\nThe next priority for the project is to take the rock solid x64 Windows\r\ndebugging experience, and port all of the relevant pieces to support local x64\r\nLinux debugging also.\r\n\r\nThe debugger has been written to abstract over the parts that need to differ on\r\neither Linux or Windows, and this is mainly going to be a task in building out\r\ndifferent backends for those abstraction layers.\r\n\r\nThe major parts of this phase are:\r\n\r\n- Porting the `src\u002Fdemon` layer to implement the Demon local process control\r\nabstraction API.\r\n- Implementing an x64 ELF Linux unwinder in the `src\u002Fctrl` layer.\r\n- Creating a DWARF-to-RDI converter (in the same way that we've built a\r\nPDB-to-RDI converter). A partial implementation of this is in\r\n`src\u002Frdi_from_dwarf`.\r\n- Porting the `src\u002Frender` layer to implement all of the rendering features the\r\nfrontend needs on a Linux-compatible API (the backend used on Windows is D3D11).\r\n- Porting the `src\u002Ffont_provider` layer to a Linux-compatible font\r\nrasterization backend, like FreeType (the backend used on Windows is\r\nDirectWrite).\r\n- Porting the `src\u002Fos` layers to Linux. This includes core operating system\r\nabstraction (virtual memory allocation, threading and synchronization\r\nprimitives, and so on), and graphical operating system abstraction (windows,\r\ninput events, and so on).\r\n\r\nOnce the above list is complete, and once every part is rock solid, the Windows\r\ndebugging experience we'll have worked diligently to create will also be\r\navailable natively on Linux machines.\r\n\r\n### And Beyond!\r\n\r\nThere are several directions we might take after these two major phases,\r\nlike remote debugging, porting to different architectures, further improving\r\nthe debugger's features (like improving the visualization engine), and so on.\r\nBut for now, we're mostly focused on those first two phases.\r\n\r\n---\r\n\r\n# Codebase Introduction\r\n\r\n## Top-Level Directory Descriptions\r\n\r\n- `data`: Small binary files which are used when building, either to embed\r\n  within build artifacts, or to package with them.\r\n- `src`: All source code.\r\n\r\nAfter setting up the codebase and building, the following directories will\r\nalso exist:\r\n\r\n- `build`: All build artifacts. Not checked in to version control.\r\n- `local`: Local files, used for local build configuration input files. Not\r\n  checked in to version control.\r\n\r\n## Layer Descriptions\r\n\r\nThe codebase is organized into *layers*. Layers are separated either to isolate\r\ncertain problems, and to allow inclusion into various builds without needing to\r\npull everything in the codebase into a build. Layers correspond with folders\r\ninside of the `src` directory. Sometimes, one folder inside of the `src`\r\ndirectory will include multiple sub-layers, but the structure is intended to be\r\nfairly flat.\r\n\r\nLayers correspond roughly 1-to-1 with *namespaces*. The term \"namespaces\" in\r\nthis context does not refer to specific namespace language features, but rather\r\na naming convention for C-style namespaces, which are written in the codebase as\r\na short prefix, usually 1-3 characters, followed by an underscore. These\r\nnamespaces are used such that the layer to which certain code belongs may be\r\nquickly understood by glancing at code. The namespaces are generally quite short\r\nto ensure that they aren't much of a hassle to write. Sometimes, multiple sub-\r\nlayers will share a namespace. A few layers do not have a namespace, but most\r\ndo. Namespaces are either all-caps or lowercase depending on the context in\r\nwhich they're used. For types, enum values, and some macros, they are\r\ncapitalized. For functions and global variables, they are lowercase.\r\n\r\nLayers depend on other layers, but circular dependencies would break the\r\nseparability and isolation utility of layers (in effect, forming one big layer),\r\nso in other words, layers are arranged into a directed acyclic graph.\r\n\r\nA few layers are built to be used completely independently from the rest of the\r\ncodebase, as libraries in other codebases and projects. As such, these layers do\r\nnot depend on any other layers in the codebase. The folders which contain these\r\nlayers are prefixed with `lib_`, like `lib_rdi`.\r\n\r\nA list of the layers in the codebase and their associated namespaces is below:\r\n- `artifact_cache` (`AC_`): Implements an asynchronously-filled cache of\r\n  computation artifacts, which are automatically evicted when not accessed. Used\r\n  for asynchronously streaming and caching process memory and file system\r\n  contents, as well as asynchronously preparing visualizer data.\r\n- `base` (no namespace): Universal, codebase-wide constructs. Strings, math,\r\n  memory allocators, helper macros, command-line parsing, and so on. Requires\r\n  no other codebase layers.\r\n- `codeview` (`CV_`): Code for parsing and writing the CodeView format.\r\n- `coff` (`COFF_`): Code for parsing and writing the COFF (Common Object File\r\n  Format) file format.\r\n- `content` (`C_`): Implements a cache for general data blobs, keyed by a\r\n  128-bit hash of the data. Also implements a keying system on top, where keys\r\n  refer to a unique identity which corresponds to a history of 128-bit hashes.\r\n  Used as a general data store by other layers.\r\n- `ctrl` (`CTRL_`): The debugger's \"control system\" layer. Implements\r\n  asynchronous process control, stepping, and breakpoints for all attached\r\n  processes. Runs in lockstep with attached processes. When it runs, attached\r\n  processes are halted. When attached processes are running, it is halted.\r\n  Driven by a debugger frontend on another thread.\r\n- `dbg_engine` (`D_`): Implements the core debugger system, without any\r\n  graphical components. This contains top-level logic for things like stepping,\r\n  launching, freezing threads, mid-run breakpoint addition, some caches, and so\r\n  on.\r\n- `dbg_info` (`DI_`): Implements asynchronous debug info conversion and loading.\r\n  Maintains a cache for loaded debug info. Loads RAD Debug Info (RDI) files.\r\n  Launches separate processes for on-demand conversion to the RDI format if\r\n  necessary. Also provides various asynchronous operations for using debug info,\r\n  like fuzzy searching across all records in loaded debug info.\r\n- `demon` (`DMN_`): An abstraction layer for local-machine, low-level process\r\n  control. The abstraction is used to provide a common interface for process\r\n  control on target platforms. Used to implement part of `ctrl`.\r\n- `disasm` (`DASM_`): Implements disassembly generation, including exposing the\r\n  ability to compute and cache disassembly asynchronously.\r\n- `draw` (`DR_`): Implements a high-level graphics drawing API for the\r\n  debugger's purposes, using the underlying `render` abstraction layer. Provides\r\n  high-level APIs for various draw commands, but takes care of batching them,\r\n  and so on.\r\n- `dwarf` (`DW_`): Code for parsing the DWARF format.\r\n- `eh` (`EH_`): Code for parsing the EH frame format.\r\n- `elf` (`ELF_`): Code for parsing the ELF format.\r\n- `eval` (`E_`): A compiler for an expression language, built for evaluation of\r\n  variables, registers, types, and more, from debugger-attached processes,\r\n  debug info, debugger state, and files. Broken into several phases mostly\r\n  corresponding to traditional compiler phases: lexer, parser, type-checker, IR\r\n  generation, and IR evaluation.\r\n- `eval_visualization` (`EV_`): Implements the core non-graphical evaluation\r\n  visualization engine, which can be used to visualize evaluations (provided by\r\n  the `eval` layer) in a number of ways. Implements core data structures and\r\n  transforms for watch tables.\r\n- `file_stream` (`FS_`): Implements asynchronous file streaming, storing the\r\n  artifacts inside of the cache implemented by the `content` and\r\n  `artifact_cache` layers, hot-reloading the contents of files when they change.\r\n  Allows callers to map file paths to data hashes, which can then be used to\r\n  obtain the file's data.\r\n- `font_cache` (`FNT_`): Implements a cache of rasterized font data, both in\r\n  CPU-side data for text shaping, and in GPU texture atlases for rasterized\r\n  glyphs. All cache information is sourced from the `font_provider` abstraction\r\n  layer.\r\n- `font_provider` (`FP_`): An abstraction layer for various font file decoding\r\n  and font rasterization backends.\r\n- `lib_raddbg_markup` (`RADDBG_`): Standalone library for marking up user\r\n  programs to work with various features in the debugger. Does not depend on\r\n  `base`, and can be independently relocated to other codebases.\r\n- `lib_rdi` (`RDI_`): Standalone library which defines the core RDI types\r\n  and helper functions for reading and writing the RDI debug info file format.\r\n  Does not depend on `base`, and can be independently relocated to other\r\n  codebases.\r\n- `lib_rdi_make` (`RDIM_`): Standalone library for constructing RDI debug info\r\n  data. Does not depend on `base`, and can be independently relocated\r\n  to other codebases.\r\n- `linker` (`LNK_`): The layer which implements the RAD Linker executable\r\n  itself.\r\n- `mdesk` (`MD_`): Code for parsing Metadesk files (stored as `.mdesk`), which\r\n  is the JSON-like (technically a JSON superset) text format used for the\r\n  debugger's user and project configuration files and metacode, which is parsed\r\n  and used to generate code with the `metagen` layer.\r\n- `metagen` (`MG_`): A metaprogram which is used to generate primarily code and\r\n  data tables. Consumes Metadesk files, stored with the extension `.mdesk`, and\r\n  generates C code which is then included by hand-written C code. Currently, it\r\n  does not analyze the codebase's hand-written C code, but in principle this is\r\n  possible. This allows easier & less-error-prone management of large data\r\n  tables, which are then used to produce e.g. C `enum`s and a number of\r\n  associated data tables. There are also a number of other generation features,\r\n  like embedding binary files or complex multi-line strings into source code.\r\n- `msf` (`MSF_`): Code for parsing and writing the MSF file format.\r\n- `msvc_crt` (`MSCRT_`): Code for parsing that's specific to the MSVC CRT.\r\n- `mule` (no namespace): Test executables for battle testing debugger\r\n  functionality.\r\n- `mutable_text` (`MTX_`): Implements an asynchronously-filled-and-mutated\r\n  cache for text buffers which are mutated across time. In the debugger, this is\r\n  used to implement the `Output` log.\r\n- `natvis` (no namespace): NatVis files for type visualization of the codebase's\r\n  types in other debuggers.\r\n- `os\u002Fcore` (`OS_`): An abstraction layer providing core, non-graphical\r\n  functionality from the operating system under an abstract API, which is\r\n  implemented per-target-operating-system.\r\n- `os\u002Fgfx` (`OS_`): An abstraction layer, building on `os\u002Fcore`, providing\r\n  graphical operating system features under an abstract API, which is\r\n  implemented per-target-operating-system.\r\n- `pdb` (`PDB_`): Code for parsing and writing the PDB file format.\r\n- `pe` (`PE_`): Code for parsing and writing the PE (Portable Executable) file\r\n  format.\r\n- `radbin` (`RB_`): The layer implementing the `radbin` binary utility\r\n  executable.\r\n- `raddbg` (`RD_`): The layer which ties everything together for the main\r\n  graphical debugger executable. Implements the debugger's graphical frontend,\r\n  all of the debugger-specific UI, the debugger executable's command line\r\n  interface, and all of the built-in visualizers.\r\n- `rdi` (`RDI_`): A layer which includes the `lib_rdi` layer and bundles it with\r\n  codebase-specific helpers, to easily include the library in codebase programs,\r\n  and have it be integrated with codebase constructs.\r\n- `rdi_from_coff` (`C2R_`): Code for converting information in COFF files to the\r\n  equivalent RDI data.\r\n- `rdi_from_dwarf` (`D2R_`): In-progress code for converting DWARF to the\r\n  equivalent RDI data.\r\n- `rdi_from_elf` (`E2R_`)): Code for converting ELF data to the equivalent RDI\r\n  data.\r\n- `rdi_from_pdb` (`P2R_`): Code for converting PDB data to the equivalent RDI\r\n  data.\r\n- `rdi_make` (`RDIM_`): A layer which includes the `lib_rdi_make` layer and\r\n  bundles it with codebase-specific helpers, to easily include the library in\r\n  codebase programs, and have it be integrated with codebase constructs.\r\n- `regs` (`REGS_`): Types, helper functions, and metadata for registers on\r\n  supported architectures. Used in reading\u002Fwriting registers in `demon`, or in\r\n  looking up register metadata.\r\n- `render` (`R_`): An abstraction layer providing an abstract API for rendering\r\n  using various GPU APIs under a common interface. Does not implement a high\r\n  level drawing API - this layer is strictly for minimally abstracting on an\r\n  as-needed basis. Higher level drawing features are implemented in the `draw`\r\n  layer.\r\n- `scratch` (no namespace): Scratch space for small and transient test programs.\r\n- `tester` (no namespace): A program used for automated testing.\r\n- `text` (`TXT_`): Implements text processing functions, like parsing line\r\n  breaks, and lexing and parsing source code. Also offers an API to do this\r\n  asynchronously.\r\n- `third_party` (no namespace): External code from other projects, which some\r\n  layers in the codebase depend on. All external code is included and built\r\n  directly within the codebase.\r\n- `ui` (`UI_`): Machinery for building graphical user interfaces. Provides a\r\n  core immediate mode hierarchical user interface data structure building\r\n  API, and has helper layers for building some higher-level widgets.\r\n","RAD Debugger 是一个原生的、用户模式下的多进程图形调试器。它支持在Windows x64环境下使用PDB进行本地调试，并计划在未来扩展到Linux平台和DWARF调试信息的支持。该项目还引入了两种相关技术：一种是自定义的RAD Debug Info (RDI)格式，用于解析和利用调试信息；另一种是RAD Linker，这是一种高性能链接器，旨在快速生成大型可执行文件并支持生成标准PDB或RAD Debug Info。目前项目处于Alpha阶段，适合于需要高效处理大规模编译项目的开发场景，以及对现有工具链有更高性能要求的开发者使用。",2,"2026-06-11 03:06:45","top_language"]