aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CGVTables.cpp
diff options
context:
space:
mode:
authorAdrian Vogelsgesang <vogelsgesang@gmail.com>2025-06-11 13:50:32 +0200
committerGitHub <noreply@github.com>2025-06-11 13:50:32 +0200
commit756e7cfd86c7f2bf20aaa1a3f87b5aa72ec128b4 (patch)
tree7e622f10bfaea4f50002b20b742bcde035c1f127 /clang/lib/CodeGen/CGVTables.cpp
parent2dd88c405d77b34dc028af09f3d55fa10dbed50e (diff)
downloadllvm-756e7cfd86c7f2bf20aaa1a3f87b5aa72ec128b4.zip
llvm-756e7cfd86c7f2bf20aaa1a3f87b5aa72ec128b4.tar.gz
llvm-756e7cfd86c7f2bf20aaa1a3f87b5aa72ec128b4.tar.bz2
[debuginfo][coro] Fix linkage name for clones of coro functions (#141889)
So far, the `DW_AT_linkage_name` of the coroutine `resume`, `destroy`, `cleanup` and `noalloc` function clones were incorrectly set to the original function name instead of the updated function names. With this commit, we now update the `DW_AT_linkage_name` to the correct name. This has multiple benefits: 1. it's easier for me (and other toolchain developers) to understand the output of `llvm-dwarf-dump` when coroutines are involved. 2. When hitting a breakpoint, both LLDB and GDB now tell you which clone of the function you are in. E.g., GDB now prints "Breakpoint 1.2, coro_func(int) [clone .resume] (v=43) at ..." instead of "Breakpoint 1.2, coro_func(int) (v=43) at ...". 3. GDB's `info line coro_func` command now allows you to distinguish the multiple different clones of the function. In Swift, the linkage names of the clones were already updated. The comment right above the relevant code in `CoroSplit.cpp` already hinted that the linkage name should probably also be updated in C++. This comment was added in commit 6ce76ff7eb7640, and back then the corresponding `DW_AT_specification` (i.e., `SP->getDeclaration()`) was not updated, yet, which led to problems for C++. In the meantime, commit ca1a5b37c7236d added code to also update `SP->getDeclaration`, as such there is no reason anymore to not update the linkage name for C++. Note that most test cases used inconsistent function names for the LLVM function vs. the DISubprogram linkage name. clang would never emit such LLVM IR. This confused me initially, and hence I fixed it while updating the test case. Drive-by fix: The change in `CGVTables.cpp` is purely stylistic, NFC. When looking for other usages of `replaceWithDistinct`, I got initially confused because `CGVTables.cpp` was calling a static function via an object instance.
Diffstat (limited to 'clang/lib/CodeGen/CGVTables.cpp')
-rw-r--r--clang/lib/CodeGen/CGVTables.cpp2
1 files changed, 1 insertions, 1 deletions
diff --git a/clang/lib/CodeGen/CGVTables.cpp b/clang/lib/CodeGen/CGVTables.cpp
index c744727..2897ccd 100644
--- a/clang/lib/CodeGen/CGVTables.cpp
+++ b/clang/lib/CodeGen/CGVTables.cpp
@@ -124,7 +124,7 @@ static void resolveTopLevelMetadata(llvm::Function *Fn,
auto *DIS = Fn->getSubprogram();
if (!DIS)
return;
- auto *NewDIS = DIS->replaceWithDistinct(DIS->clone());
+ auto *NewDIS = llvm::MDNode::replaceWithDistinct(DIS->clone());
VMap.MD()[DIS].reset(NewDIS);
// Find all llvm.dbg.declare intrinsics and resolve the DILocalVariable nodes