[llvm] [RFC] Emit dwarf data for signature-changed or new functions (PR #157349)

via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 20 09:53:00 PDT 2025


yonghong-song wrote:

> Let's consider the case if we have two functions in the source code:
> 
> ```c++
> int foo(int x, int y) { ... }
> int foo(int x) { ... }
> ```
> 
> And let's assume that the second argument of `foo(int, int)` is optimized out (so that the second argument is removed from the definition DISubprogram's arguments, by EmitChangedFuncDebugInfo).
> 
> If we try to execute `print foo(5)` in debugger, will debugger correctly resolve the overloaded functions call?

I tried the following example:
```
$ cat main.cc
int test(int x, int y);

int main(void) {
  return test(5, 10);
}

$ cat same_func_name.cc
#include <stdio.h>

__attribute__((noinline)) int foo(int x, int y) {
  printf("x = %d\n", x);
  return x;
}
__attribute__((noinline)) int foo(int x) {
  printf("x * x = %d\n", x * x);
  return x;
}
int test(int x, int y) {
  return foo(x, y) + foo(x);
}
$ cat run.sh
clang++ -O2 -g same_func_name.cc main.cc -o same_func_name -mllvm -print-after-all
$
```
Right before EmitChangedFuncDebugInfoPass, we have
```
define dso_local noundef i32 @_Z3fooii(i32 noundef returned %x, i32 %y) local_unnamed_addr #0 !dbg !23 {
entry:
    #dbg_value(i32 %x, !28, !DIExpression(), !30)
    #dbg_value(i32 poison, !29, !DIExpression(), !30)
  %call = tail call i32 (ptr, ...) @printf(ptr noundef nonnull dereferenceable(1) @.str, i32 noundef %x), !dbg !31
  ret i32 %x, !dbg !32
}

define dso_local noundef i32 @_Z3fooi(i32 noundef returned %x) local_unnamed_addr #0 !dbg !39 {
entry:
    #dbg_value(i32 %x, !43, !DIExpression(), !44)
  %mul = mul nsw i32 %x, %x, !dbg !45
  %call = tail call i32 (ptr, ...) @printf(ptr noundef nonnull dereferenceable(1) @.str.1, i32 noundef %mul), !dbg !46
  ret i32 %x, !dbg !47
}
```

So for the below function
```
__attribute__((noinline)) int foo(int x, int y) {
  printf("x = %d\n", x);
  return x;
}
```
Although parameter 'y' is marked as 'poison' and will not be used, the function signature for `_Z3fooii` will remain the same. Not sure whether this is a particular C++ feature or not.


https://github.com/llvm/llvm-project/pull/157349


More information about the llvm-commits mailing list