[Bug symtab/25874] New: Printing variables after noreturn functions use the wrong DWARF info

[Bug symtab/25874] New: Printing variables after noreturn functions use the wrong DWARF info

[ricky at rzhou dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25874

            Bug ID: 25874
           Summary: Printing variables after noreturn functions use the
                    wrong DWARF info
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: ricky at rzhou dot org
  Target Milestone: ---

Created attachment 12490
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12490&action=edit
bug1

In the following program:

```
#include <stdio.h>
#include <stdlib.h>

template<typename T>
void no_optimize(T& v) {
  asm volatile("" : "+m"(v));
}

void crash() {
  printf("test\n");
  __builtin_debugtrap();
  abort();
}

int main(int argc, char** argv) {
  bool a = true;
  bool b = true;

  no_optimize(a);
  no_optimize(b);
  if (a && b) {
    crash();
  }

  printf("a = %d, b = %d\n", a, b);
  return 0;
}
```

compiled with:

```
clang++ -O1 -g -fno-exceptions -o bug1 bug1.cc
```

(see attached binary)

Attempting to print "b" at the breakpoint prints an invalid value:

```
$ gdb ./bug1
(gdb) r
Starting program: /tmp/bug1
test

Program received signal SIGTRAP, Trace/breakpoint trap.
crash () at bug1.cc:12
12        abort();
=> 0x000000000040115c <crash()+12>:     e8 df fe ff ff  callq  0x401040
<abort@plt>
   0x0000000000401161:  66 2e 0f 1f 84 00 00 00 00 00   nopw  
%cs:0x0(%rax,%rax,1)
   0x000000000040116b:  0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
(gdb) up
#1  0x00000000004011b8 in main (argc=<optimized out>, argv=<optimized out>) at
bug1.cc:22
22          crash();
   0x00000000004011b3 <main(int, char**)+67>:   e8 98 ff ff ff  callq  0x401150
<crash()>
(gdb) p b
$1 = 5
(gdb) info address b
Symbol "b" is multi-location:
  Range 0x401176-0x40118a: the constant 1
  Range 0x40118a-0x401198: a complex DWARF expression:
     0: DW_OP_breg7 6 [$rsp]

  Range 0x401198-0x4011aa: a variable in $rax
  Range 0x4011b3-0x4011b8: a variable in $rax
.
(gdb) p $rax
$2 = 5
(gdb) x/i $pc
=> 0x4011b8:    nopl   0x0(%rax,%rax,1)
(gdb) disas
Dump of assembler code for function main(int, char**):
   0x0000000000401170 <+0>:     push   %rax
   0x0000000000401171 <+1>:     movb   $0x1,0x7(%rsp)
   0x0000000000401176 <+6>:     movb   $0x1,0x6(%rsp)
   0x000000000040117b <+11>:    lea    0x7(%rsp),%rdi
   0x0000000000401180 <+16>:    callq  0x4011c0 <no_optimize<bool>(bool&)>
   0x0000000000401185 <+21>:    lea    0x6(%rsp),%rdi
   0x000000000040118a <+26>:    callq  0x4011c0 <no_optimize<bool>(bool&)>
   0x000000000040118f <+31>:    movzbl 0x7(%rsp),%esi
   0x0000000000401194 <+36>:    mov    0x6(%rsp),%al
   0x0000000000401198 <+40>:    test   %esi,%esi
   0x000000000040119a <+42>:    je     0x4011a0 <main(int, char**)+48>
   0x000000000040119c <+44>:    test   %al,%al
   0x000000000040119e <+46>:    jne    0x4011b3 <main(int, char**)+67>
   0x00000000004011a0 <+48>:    movzbl %al,%edx
   0x00000000004011a3 <+51>:    mov    $0x402004,%edi
   0x00000000004011a8 <+56>:    xor    %eax,%eax
   0x00000000004011aa <+58>:    callq  0x401030 <printf@plt>
   0x00000000004011af <+63>:    xor    %eax,%eax
   0x00000000004011b1 <+65>:    pop    %rcx
   0x00000000004011b2 <+66>:    retq
   0x00000000004011b3 <+67>:    callq  0x401150 <crash()>
End of assembler dump.
```

Even though pc is 0x4011b8, which is out of range of "Range 0x4011b3-0x4011b8:
a variable in $rax", the value of $rax (which now contains the return value of
printf) is printed for "b".

The bug seems to be that get_frame_address_in_block [0], called from places
such as [1] sometimes subtracts 1 from pc when it points past the end of a
function (as it can sometimes do after a call to a noreturn function). This may
make sense in some places where pc needs to point inside of a function, but not
for matching DWARF address ranges, where the end address is exclusive.

[0]
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/frame.c;h=ac1016b083fc17a51373d51b875cb03bf5bc2b56;hb=HEAD#l2425
[1]
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/dwarf2/loc.c;h=5b690ca9276ed1accd55ec03f97667a1bde7913e;hb=HEAD#l4426

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/25874] Printing variables after noreturn functions uses the wrong DWARF info

[ricky at rzhou dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25874

Ricky Zhou <ricky at rzhou dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Printing variables after    |Printing variables after
                   |noreturn functions use the  |noreturn functions uses the
                   |wrong DWARF info            |wrong DWARF info

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/25874] Printing variables after noreturn functions uses the wrong DWARF info

[ricky at rzhou dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25874

--- Comment #1 from Ricky Zhou <ricky at rzhou dot org> ---
Created attachment 12491
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12491&action=edit
not-very-well-tested patch

The attached patch attempts to fix up some uses of get_frame_address_in_block,
but the code is gnarly enough that I am not super confident about the patch's
correctness. It also doesn't get every single suspicious-looking call, for
example, the call to get_frame_address_in_block_if_available in dwarf2/loc.c.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/25874] Printing variables after noreturn functions uses the wrong DWARF info

[ricky at rzhou dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25874

Ricky Zhou <ricky at rzhou dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #2 from Ricky Zhou <ricky at rzhou dot org> ---
Upon further reading, this looks like a duplicate of bug 25143 (see also the
corresponding Clang bug, https://bugs.llvm.org/show_bug.cgi?id=39752).

Looking at some of the discussion linked from the LLVM bug
(http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2018-December/004500.html)
it looks like the correctness of fudging PC values is much more controversial
than I could have imagined!

I now see that doing so does resolve the ambiguity between "right after the
last instruction of a function" and "first instruction of the next function".

*** This bug has been marked as a duplicate of bug 25143 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.