[llvm-bugs] [Bug 25028] New: [mips64] Incorrect dwarf info

[via llvm-bugs]

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

            Bug ID: 25028
           Summary: [mips64] Incorrect dwarf info
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dean at codeplay.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 14983
  --> https://llvm.org/bugs/attachment.cgi?id=14983&action=edit
Bitcode

Hi,

I have got a case where the mips64el compiler creates incorrect dwarf info, as
far as I can understand. The bitcode is originally generated from an Android
RenderScript source file, attached for reference. It contains two functions
(test1 and test2), both marked with the attribute no-frame-pointer-elim, which
should keep the usage of the register $fp (r30). I am building the final object
with:

llc -relocation-model=pic -filetype=obj -mtriple=mips64el-none-linux-android -o
dummy.o dummy.bc


Looking into the generated assembler for the function test2: 

test2:
      98: 60 fd bd 67   daddiu  $sp, $sp, -672
      9c: 98 02 bf ff   sd  $ra, 664($sp)
      a0: 90 02 be ff   sd  $fp, 656($sp)
      a4: 88 02 bc ff   sd  $gp, 648($sp)
      a8: 80 02 b7 ff   sd  $23, 640($sp)
      ac: 78 02 b6 ff   sd  $22, 632($sp)
      b0: 70 02 b5 ff   sd  $21, 624($sp)
      b4: 68 02 b4 ff   sd  $20, 616($sp)
      b8: 60 02 b3 ff   sd  $19, 608($sp)
      bc: 58 02 b2 ff   sd  $18, 600($sp)
      c0: 50 02 b1 ff   sd  $17, 592($sp)
      c4: 48 02 b0 ff   sd  $16, 584($sp)
      c8: 25 f0 a0 03   move   $fp, $sp
      cc: e0 ff 1c 64   daddiu  $gp, $zero, -32
      d0: 24 e8 bc 03   and $sp, $sp, $gp
      d4: 00 08 04 00   sll $1, $4, 0
      d8: 44 02 a1 af   sw  $1, 580($sp)
      dc: 44 02 a1 93   lbu $1, 580($sp)
      e0: 45 02 a2 93   lbu $2, 581($sp)
      e4: 46 02 a3 93   lbu $3, 582($sp)
      e8: 47 02 a4 93   lbu $4, 583($sp)
      ec: 43 02 a4 a3   sb  $4, 579($sp)
      f0: 42 02 a3 a3   sb  $3, 578($sp)
      f4: 41 02 a2 a3   sb  $2, 577($sp)
      f8: 40 02 a1 a3   sb  $1, 576($sp)
      fc: 01 00 01 64   daddiu  $1, $zero, 1
     100: 3c 0c 01 00   dsll32  $1, $1, 16
     104: 18 00 02 3c   lui $2, 24
     108: 02 00 03 3c   lui $3, 2
     10c: 03 00 04 3c   lui $4, 3
     110: 61 00 05 24   addiu $5, $zero, 97
     114: 3c 02 a5 a3   sb  $5, 572($sp)
...


The address 110 in .text should correspond to the assignment in the source file
char_local = 'a';. Its value is subsequently stored at the position $sp + 572 .
 Note that the $fp and $sp match at the address c8, however the $sp is further
moved at the address d0, potentially implying $sp != $fp hereafter.

Looking at the dwarf info, it says that the base address for the function test2
is the $fp: 

 <1><46>: Abbrev Number: 3 (DW_TAG_subprogram)
    <47>   DW_AT_low_pc      : 0x0
    <4f>   DW_AT_high_pc     : 0x94
    <53>   DW_AT_frame_base  : 1 byte block: 6e   (DW_OP_reg30 (r30))
    <55>   DW_AT_name        : (indirect string, offset: 0xc6): test1
    <59>   DW_AT_decl_file   : 1
    <5a>   DW_AT_decl_line   : 5
    <5b>   DW_AT_prototyped  : 1
    <5b>   DW_AT_type        : <0x36d>
    <5f>   DW_AT_external    : 1

and that the local variable char_local is at $fp + 572:

 <2><c0>: Abbrev Number: 5 (DW_TAG_variable)
    <c1>   DW_AT_location    : 3 byte block: 91 bc 4  (DW_OP_fbreg: 572)
    <c5>   DW_AT_name        : (indirect string, offset: 0x111): char_local
    <c9>   DW_AT_decl_file   : 1
    <ca>   DW_AT_decl_line   : 17
    <cb>   DW_AT_type        : <0x2a>

which is wrong as the $fp != $sp.

Tested with the tip of LLVM.

-- 
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/20151002/9ef12d82/attachment.html>