llvm / llvm/llvm-project

[clang][DebugInfo] Thunks created by `CodeGenFunction::GenerateVarArgsThunk` have incorrect parameters list in DWARF

Open
#168,082 2 comments 0 reactions 0 assignees View on GitHub
clang:codegen debuginfo
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

Consider the test `clang/test/CodeGenCXX/tmp-md-nodes2.cpp` (https://github.com/llvm/llvm-project/blob/94c751d6b5e202455cc67a432d4b69979b132051/clang/test/CodeGenCXX/tmp-md-nodes2.cpp).
When compiled with
```
clang -O2 -g llvm-project/clang/test/CodeGenCXX/tmp-md-nodes2.cpp -o tmp-md-nodes2.o -target riscv64-unknown-linux-gnu -c
```
we get the following dwarf:
```
// Declaration of CBdVfsImpl::ReqCacheHint
0x0000004d: DW_TAG_subprogram
DW_AT_linkage_name ("_ZN10CBdVfsImpl12ReqCacheHintEP9CMsgAgentN3CFs10CACHE_HINTEz")
DW_AT_declaration (true)
...
0x0000005e: DW_TAG_formal_parameter
...
0x00000063: DW_TAG_formal_parameter
...
0x00000068: DW_TAG_formal_parameter
...
0x0000006d: DW_TAG_unspecified_parameters
0x0000006e: NULL

// Definition of CBdVfsImpl::ReqCacheHint
0x000000d0: DW_TAG_subprogram
DW_AT_low_pc (0x0000000000000000)
DW_AT_high_pc (0x0000000000000012)
DW_AT_specification (0x0000004d "_ZN10CBdVfsImpl12ReqCacheHintEP9CMsgAgentN3CFs10CACHE_HINTEz")
...
0x000000e1: DW_TAG_formal_parameter
...
0x000000e7: DW_TAG_formal_parameter
...
0x000000ef: DW_TAG_formal_parameter
...
0x000000f7: DW_TAG_unspecified_parameters
0x000000f8: NULL

// Definition of CBdVfsImpl::ReqCacheHint thunk produced by CodeGenFunction::GenerateVarArgsThunk
0x000000f9: DW_TAG_subprogram
DW_AT_low_pc (0x0000000000000012)
DW_AT_high_pc (0x0000000000000024)
DW_AT_specification (0x0000004d "_ZN10CBdVfsImpl12ReqCacheHintEP9CMsgAgentN3CFs10CACHE_HINTEz")
...
0x00000106: DW_TAG_unspecified_parameters
0x00000107: NULL
```

For thunks created by `CodeGenFunction::GenerateVarArgsThunk`, optimized-out formal parameters are not emitted. Thus, if we break at thunk in lldb, we don't see the list of parameters when executing `frame var -l`.

The problem lies in the way how `CodeGenFunction::GenerateVarArgsThunk` clones function metadata. It manually clones DISubprogram of the original function for thunk, preventing its retainedNodes list (which passes the information about optimized-out arguments to DwarfDebug) from being remapped inside `CloneFunction`. The motivation was given in https://reviews.llvm.org/D39396: `CodeGenFunction::GenerateVarArgsThunk` tries to prevent `CloneFunction` from remapping DISubprogram, since some metadata nodes are still unresolved by the moment `CodeGenFunction::GenerateVarArgsThunk` is called.

This could be resolved by postponing the emission of thunks to later stages of LLVM IR generation in Clang (see discussion in https://github.com/llvm/llvm-project/pull/167758).

Contributor guide

Open the contributing guide

Research direction

Start with clang/test/CodeGenCXX/tmp-md-nodes2.cpp and CodeGenFunction::GenerateVarArgsThunk. Reproduce the RISC-V DWARF output, then inspect how thunk function metadata is cloned and how retainedNodes are handled. Done means the generated thunk DWARF includes the optimized-out formal parameters so LLDB can show them with frame var -l.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.