llvm-project

756e7cfd - [debuginfo][coro] Fix linkage name for clones of coro functions (#141889)

[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.