[llvm-bugs] [Bug 49641] New: Incorrect location range for local variable in the register clobbered by callee for GDB tune

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49641

            Bug ID: 49641
           Summary: Incorrect location range for local variable in the
                    register clobbered by callee for GDB tune
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: djordje.todorovic at syrmia.com
                CC: jdevlieghere at apple.com, keith.walker at arm.com,
                    llvm-bugs at lists.llvm.org,
                    paul_robinson at playstation.sony.com

Please consider these two files:

$ cat test2.c
void f1(int);
int f2();
void f3();

void f() {
  f1(0);
  int local = f2();
  f1(local);
  f3();
}

$ cat main-for-core.c
#include <stdio.h>

void f1(int param) {
  if (param % 2 == 0)
    return;
  printf("HELLO\n");
  abort();
}

int f2() {
  int x;
  scanf("%d", &x);
  return x;
}

void f3() {
  int y;
  scanf("%d", &y);
  printf("%d\n", y);
}

int main() {
  f();
  return 0;
}

Compilation of the files:

$ clang -g -O2 test2.c -c -o object-file-test2.o
$ clang -g -O2 main-for-core.c object-file-test2.o -o main-for-core

By examining debug_loc from object-file-test2.o for the `local` var we see:
00000000 000000000000000f 0000000000000016 (DW_OP_reg0 (rax))

And the code for the f() is:
0000000000000000 <f>:
0: push %rax
1: xor %edi,%edi
3: callq 8 <f+0x8>
8: xor %eax,%eax
a: callq f <f+0xf>
f: mov %eax,%edi
11: callq 16 <f+0x16>
16: xor %eax,%eax
18: pop %rcx
19: jmpq 1e <f+0x1e>

While debugging it, by loading the core file generated due to abort() (as an
input I typed 5):

$ gdb main-for-core
...
(gdb) bt
#0 0x00007fb2d7aeb377 in raise () from /lib64/libc.so.6
#1 0x00007fb2d7aeca68 in abort () from /lib64/libc.so.6
#2 0x0000000000401197 in f1 (param=<optimized out>) at main-for-core.c:7
#3 0x0000000000401216 in f () at test2.c:8
#4 0x00000000004011f8 in main () at main-for-core.c:23
(gdb) f 3
#3 0x0000000000401216 in f () at test2.c:8
8 f1(local);
(gdb) disassemble
Dump of assembler code for function f:
0x0000000000401200 <+0>: push %rax
0x0000000000401201 <+1>: xor %edi,%edi
0x0000000000401203 <+3>: callq 0x401180 <f1>
0x0000000000401208 <+8>: xor %eax,%eax
0x000000000040120a <+10>: callq 0x4011a0 <f2>
0x000000000040120f <+15>: mov %eax,%edi
0x0000000000401211 <+17>: callq 0x401180 <f1>
=> 0x0000000000401216 <+22>: xor %eax,%eax
0x0000000000401218 <+24>: pop %rcx
0x0000000000401219 <+25>: jmpq 0x4011c0 <f3>
End of assembler dump.
(gdb) p local
$1 = 0

But it should be reported as <optimized_out>, because the %eax was clobbered by
the call.

GCC produces different high pc address to keep GDB working properly:
00000000 000000000000000f 0000000000000015 (DW_OP_reg0 (rax))

LLDB works OK for this case.

I've tried to change the DwarfDebug, to generate the debug loc entry ending
address as addr(endLabel) - 1, as GCC, for GDB tune, and it works -- GDB prints
optimized_out for the local var.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210319/93b312e0/attachment.html>