[llvm-bugs] [Bug 46643] New: [DWARF] call_site/entry_value not guarded properly

[via llvm-bugs]

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

            Bug ID: 46643
           Summary: [DWARF] call_site/entry_value not guarded properly
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: paul_robinson at playstation.sony.com
                CC: jdevlieghere at apple.com, keith.walker at arm.com,
                    llvm-bugs at lists.llvm.org,
                    paul_robinson at playstation.sony.com

My understanding is that DW_TAG_call_site and DW_OP_entry_value 
should be emitted only when the target debugger is GDB or LLDB.
And, when the target DWARF version is less than 5, these should
use the GNU extension codes rather than the standard v5 codes.

It doesn't seem to work that way, at least not completely.
Here's a sample source derived from what's documented in 
llvm/test/DebugInfo/MIR/X86/DW_OP_entry_value.mir :

int global;
int foo(int p, int q, int r) {
  global = p + 1;
  asm __volatile("" : : : "edi", "esi", "edx");
  return 123;
}
int bar() {
  foo(12, 13, 14);
  return global;
}

Compiled for Linux, we see the expected stuff.

$ clang -c -gdwarf-5 -O1 t.cpp -target x86_64-pc-linux
$ llvm-dwarfdump -debug-info t.o | grep call_site
0x00000070:     DW_TAG_call_site
0x00000076:       DW_TAG_call_site_parameter
0x0000007b:       DW_TAG_call_site_parameter
0x00000082:       DW_TAG_call_site_parameter
$ llvm-dwarfdump -debug-info t.o | grep entry_value
                     [0x0000000000000003, 0x000000000000000f):
DW_OP_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value)
                    DW_AT_call_value    (DW_OP_entry_value(DW_OP_reg4 RSI))
                    DW_AT_call_value    (DW_OP_entry_value(DW_OP_reg1 RDX))
$

Compiled for PS4 (so debugger tuning is "sce") and DWARF v5, we see this:

$ clang -c -gdwarf-5 -O1 t.cpp -target x86_64-scei-ps4
$ llvm-dwarfdump -debug-info t.o | grep call_site
0x0000006e:     DW_TAG_call_site
$ llvm-dwarfdump -debug-info t.o | grep entry_value
                     [0x0000000000000002, 0x0000000000000011):
DW_OP_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value)
$

Even for DWARF v4 (the PS4 default) the DW_OP_entry_value remains,
and even uses the v5 standard opcode instead of the v4 GNU extension:

$ clang -c -gdwarf-4 -O1 t.cpp -target x86_64-scei-ps4
$ llvm-dwarfdump -debug-info t.o | grep call_site
$ llvm-dwarfdump -debug-info t.o | grep entry_value
                     [0x0000000000000002, 0x0000000000000011):
DW_OP_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value)
$

The conditions for emitting this information need to be tightened up.

(Note: I am looking at supporting call_site/entry_value for the
Sony debugger, but it's unlikely to be in a near-term release, and
in the meantime we'd rather not be emitting DWARF we can't use.)

-- 
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/20200708/7ea7eea0/attachment.html>