[llvm] [dyndbg] Add SHT_LLVM_DYNDBG_ELF to Dynamic Debugging docs (PR #213853)

Orlando Cazalet-Hyams via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 4 00:07:24 PDT 2026


https://github.com/OCHyams created https://github.com/llvm/llvm-project/pull/213853

None

>From 29e87ef591aad15bddf38038f1f10ae0614f1a81 Mon Sep 17 00:00:00 2001
From: Orlando Cazalet-Hyams <orlando.hyams at sony.com>
Date: Tue, 4 Aug 2026 08:06:09 +0100
Subject: [PATCH] [dyndbg] Add SHT_LLVM_DYNDBG_ELF to Dynamic Debugging docs

---
 llvm/docs/DynamicDebugging.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/llvm/docs/DynamicDebugging.md b/llvm/docs/DynamicDebugging.md
index c3026d5800032..79ebfa230668f 100644
--- a/llvm/docs/DynamicDebugging.md
+++ b/llvm/docs/DynamicDebugging.md
@@ -23,7 +23,7 @@ Important info:
 
 ## Nested object design
 
-The broad idea is that the unoptimized program (“inner object”) is compiled and stored in a new `.debug_llvm_dyndbg` section in the optimized version (“outer object"). “Nesting” the objects allows build systems and other tools to continue to manage a single object file per translation unit.
+The broad idea is that the unoptimized program (“inner object”) is compiled and stored in a new section in the optimized version (“outer object"). “Nesting” the objects allows build systems and other tools to continue to manage a single object file per translation unit.
 
 High level nested object design:
 
@@ -40,7 +40,7 @@ This diagram illustrates the result of compiling a simple source example:
 
 `llvm::prepareForDynamicDebugging` is an LLVM utility that clones the input module without global variable definitions, renames the functions as appropriate, and generates aliases as needed in the original (to-be-optimized) module.
 
-Clang calls `llvm::prepareForDynamicDebugging` after CodeGen (`clang::emitBackendOutput`) and runs a separate optimization pipeline (`emitAssembly`), set to optimization level `O0`, on the unoptimized module. The binary output is embedded into the to-be-optimized module (using `embedBufferInModule`) to be embedded in a `.debug_llvm_dyndbg` section.
+Clang calls `llvm::prepareForDynamicDebugging` after CodeGen (`clang::emitBackendOutput`) and runs a separate optimization pipeline (`emitAssembly`), set to optimization level `O0`, on the unoptimized module. The binary output is embedded into the to-be-optimized module (using `embedBufferInModule`) to be embedded in a section of type `SHT_LLVM_DYNDBG_ELF` named `.debug_llvm_dyndbg`.
 
 It's essential for the debugger's run-time detour patching that the inner and outer function interfaces are identical. To block interprocedural optimizations `noipa` is applied to functions in the outer module. In order for the debugger to switch to an unoptimized function it must exist, so we block function specialization through `noipa` and `nooutline`.
 
@@ -48,7 +48,7 @@ Functions are padded to prevent the debugger writing over unrelated program byte
 
 ## Linker implementation
 
-In a link with dynamic debugging enabled, ELF LLD basically performs a relocatable link of the inner (unoptimized) objects within the regular link of the outer (optimized) objects. The outer link includes the symbol dependencies of any inner objects. The result of the inner relocatable link is placed in the `.debug_llvm_dyndbg` output section of the outer link output. For executable outputs, the inner relocatable link uses the option `--force-group-allocation` to resolve groups and discards groups. It also enables merging of the input sections. This helps to reduce the size of the final `.debug_llvm_dyndbg` output section for executables, especially for input objects that use `-ffunction-sections`. For relocatable output, the inner relocatable link is the same as a regular ELF relocatable link.
+In a link with dynamic debugging enabled, ELF LLD basically performs a relocatable link of the inner (unoptimized) objects within the regular link of the outer (optimized) objects. The outer link includes the symbol dependencies of any inner objects. The result of the inner relocatable link is placed in the `SHT_LLVM_DYNDBG_ELF` `.debug_llvm_dyndbg` output section of the outer link output. For executable outputs, the inner relocatable link uses the option `--force-group-allocation` to resolve groups and discards groups. It also enables merging of the input sections. This helps to reduce the size of the final `.debug_llvm_dyndbg` output section for executables, especially for input objects that use `-ffunction-sections`. For relocatable output, the inner relocatable link is the same as a regular ELF relocatable link.
 
 The key changes required to ELF LLD are to support the nested linking and to handle the symbol dependencies from the inner (unoptimized) objects to the outer (optimized) objects and the final executable output.
 



More information about the llvm-commits mailing list