[LLVMbugs] [Bug 24117] New: ARM64 debug info empty prologue

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Jul 14 03:58:41 PDT 2015


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

            Bug ID: 24117
           Summary: ARM64 debug info empty prologue
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: kuba.brecka at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I'm seeing a regression in generated debug line information for ARM64 with -O1,
on Darwin.  Consider this simple C source:

$ cat ditest.c
  #include <stdlib.h>
  int main() {
    char *x = (char*)malloc(10 * sizeof(char));
    return x[5];
  }

If I compile this with LLVM 3.6.0, and then ask `atos` to retrieve the source
line for the `malloc` call instruction, it correctly says that it's line 3:

$ ~/llvm-3.6.0/bin/clang ditest.c -o ditest -arch arm64 -g -O1
$ otool -tv ditest
  ditest:
  (__TEXT,__text) section
  _main:
  0000000100007f6c    stp x29, x30, [sp, #-16]!
  0000000100007f70    mov  x29, sp
  0000000100007f74    movz    w0, #0xa
  0000000100007f78    bl  0x100007f88 ; symbol stub for: _malloc
  0000000100007f7c    ldrsb   w0, [x0, #5]
  0000000100007f80    ldp x29, x30, [sp], #16
  0000000100007f84    ret
$ atos -o ditest 0000000100007f78
  main (in ditest) (ditest.c:3)

However, if I do the same with current LLVM trunk, `atos` says the same
instruction has source line number 2:

$ ~/llvm-trunk/bin/clang ditest.c -o ditest -arch arm64 -g -O1
$ otool -tv ditest
  ditest:
  (__TEXT,__text) section
  _main:
  0000000100007f6c    stp x29, x30, [sp, #-16]!
  0000000100007f70    mov  x29, sp
  0000000100007f74    movz    w0, #0xa
  0000000100007f78    bl  0x100007f88 ; symbol stub for: _malloc
  0000000100007f7c    ldrsb   w0, [x0, #5]
  0000000100007f80    ldp x29, x30, [sp], #16
  0000000100007f84    ret
$ atos -o ditest 0000000100007f78
  main (in ditest) (ditest.c:2)

The difference in the DWARF line info is in the way how the end of prologue is
marked, current LLVM trunk emits:

$ dwarfdump --debug-line ditest.dSYM/Contents/Resources/DWARF/ditest
...
0x0000002b: DW_LNE_set_address( 0x0000000100007f6c )
0x00000036: address += 0,  line += 1
            0x0000000100007f6c      1      2      0 is_stmt
0x00000037: DW_LNS_set_column( 20 )
0x00000039: DW_LNS_set_prologue_end
0x0000003a: address += 0,  line += 1
            0x0000000100007f6c      1      3     20 is_stmt prologue_end

Where it looks like the `address += 0` indicates that the prologue of the
function is empty, which isn't true.  The generated line information then
contains a duplicate definition for address `0x0000000100007f6c`, I don't know
if that's valid or not.

-- 
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/20150714/a262f3a2/attachment.html>


More information about the llvm-bugs mailing list