756e7cfd86
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.
The LLVM Compiler Infrastructure
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called "LLVM". This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Getting the Source Code and Building LLVM
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Getting in touch
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.