[LLVMbugs] [Bug 13599] New: Debug info says 'this' is at %rsp-8, but it's not there yet

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=13599

             Bug #: 13599
           Summary: Debug info says 'this' is at %rsp-8, but it's not
                    there yet
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: dgregor at apple.com, echristo at gmail.com,
                    llvmbugs at cs.uiuc.edu, nlewycky at google.com
    Classification: Unclassified


Created attachment 9050
  --> http://llvm.org/bugs/attachment.cgi?id=9050
Preprocessed source

$ third_party/llvm-build/Release+Asserts/bin/clang++ --version
clang version 3.2 (trunk 161353)

In the following gdb log, the address of 'storage_' is 0x7fffd149b100, but
stepping into its method claims its address is '0xffff8cd0'. This appears to
happen because the 'step' halts at address 0x00007ffff508e480, before 'this' is
stored into its alloca, and the debug information is incorrect at that
instruction.

(gdb) s
gfx::ImageSkia::operator SkBitmap& (this=0x7fffd149b100)
    at ../../ui/gfx/image/image_skia.cc:169
169       if (isNull())
(gdb) s
gfx::ImageSkia::isNull (this=0x7fffd149b100) at
../../ui/gfx/image/image_skia.h:99
99        bool isNull() const { return storage_ == NULL; }
(gdb) s
scoped_refptr<gfx::internal::ImageSkiaStorage>::operator
gfx::internal::ImageSkiaStorage*
    (this=0xffff8cd0) at ../../base/memory/ref_counted.h:252
252       operator T*() const { return ptr_; }
(gdb) p this
$27 = (const scoped_refptr<gfx::internal::ImageSkiaStorage> *) 0xffff8cd0
(gdb) p ptr_
Cannot access memory at address 0xffff8cd0
(gdb) disas
Dump of assembler code for function
scoped_refptr<gfx::internal::ImageSkiaStorage>::operator
gfx::internal::ImageSkiaStorage*() const:
=> 0x00007ffff508e480 <+0>:     mov    %rdi,-0x8(%rsp)
   0x00007ffff508e485 <+5>:     mov    -0x8(%rsp),%rdi
   0x00007ffff508e48a <+10>:    mov    (%rdi),%rax
   0x00007ffff508e48d <+13>:    retq   
End of assembler dump.
(gdb) p /x $rdi
$29 = 0x7fffd149b100
(gdb) p /x *(void**)($rsp - 8)
$30 = 0xffff8cd0


I think the relevant chunk of IR is:

define %class.SkBitmap*
@_ZNK3gfx9ImageSkiacvR8SkBitmapEv(%"class.gfx::ImageSkia"* %this) nounwind
uwtable align 2 {
entry:
  %retval = alloca %class.SkBitmap*, align 8
  %this.addr = alloca %"class.gfx::ImageSkia"*, align 8
  store %"class.gfx::ImageSkia"* %this, %"class.gfx::ImageSkia"** %this.addr,
align 8
  call void @llvm.dbg.declare(metadata !{%"class.gfx::ImageSkia"** %this.addr},
metadata !7219), !dbg !7221
  %this1 = load %"class.gfx::ImageSkia"** %this.addr
  ...

!7219 = metadata !{i32 786689, metadata !5214, metadata !"this", metadata
!4031, i32 16777384, metadata !7220, i32 64, i32 0} ; [ DW_TAG_arg_variable ]
[this] [line 168]
!7220 = metadata !{i32 786447, null, metadata !"", null, i32 0, i64 64, i64 64,
i64 0, i32 0, metadata !5123} ; [ DW_TAG_pointer_type ] [line 0, size 64, align
64, offset 0] [from ]
!7221 = metadata !{i32 168, i32 12, metadata !5214, null}
!5214 = metadata !{i32 786478, i32 0, metadata !4029, metadata !"operator class
SkBitmap &", metadata !"operator class SkBitmap &", metadata
!"_ZNK3gfx9ImageSkiacvR8SkBitmapEv", metadata !4031, i32 168, metadata !5138,
i1 false, i1 true, i32 0, i32 0, null, i32 256, i1 false, %class.SkBitmap*
(%"class.gfx::ImageSkia"*)* @_ZNK3gfx9ImageSkiacvR8SkBitmapEv, null, metadata
!5137, metadata !4024, i32 168} ; [ DW_TAG_subprogram ] [line 168] [def]
[operator class SkBitmap &]

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.