[lldb-dev] breakpoint command

[Malea, Daniel]

Hi,

I'm reading the patch but only got through a small portion of it thus far. The interface changes look all right, to me at least. I'm not too familiar with generating split-file debug info, but I imagine it's possible to do so with some flags to GCC (if not Clang)? If so, can you add some tests that do that too? I'd love to see this functionality go in and stay unbroken :)

In any case, it's probably best to have someone else with more object file experience review the patch too as my knowledge is somewhat limited in that dept. I'll post any comments I might come up with on phabricator.

Cheers,
Dan

From: Mike Sartain <mikesart at valvesoftware.com<mailto:mikesart at valvesoftware.com>>
Date: Thursday, 20 June, 2013 8:47 PM
To: Mike Sartain <mikesart at valvesoftware.com<mailto:mikesart at valvesoftware.com>>
Cc: "lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>" <lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>>
Subject: Re: [lldb-dev] breakpoint command

On Wed, Jun 19, 2013 at 2:49 PM, Michael Sartain <mikesart at valvesoftware.com<mailto:mikesart at valvesoftware.com>> wrote:
So I think the change would be in how lldb handles what the second line table entry is? Ie, skip duplicate entries.

I've added to this patch:

http://llvm-reviews.chandlerc.com/D960

Modified Symbol::GetPrologueByteSize() in source/Symbol/Symbol.cpp and Function::GetPrologueByteSize() in source/Symbol/Function.cpp. They should both now skip line entries until they find a line number that differs.

One question: would it make sense to have Symbol::GetPrologueByteSize() check to see if it is an exact alias to a function and if so, use the Function::GetPrologueByteSize() routine? That way we'd get the prologue end data instead of just skipping lines?

In any case, breakpoint setting in the printf case works as it should now:

(lldb) b printf
Breakpoint 2: where = libc.so.6`__printf + 91 at printf.c:34, address = 0x00007f8dba8b189b
(lldb) b __printf
Breakpoint 3: where = libc.so.6`__printf + 91 at printf.c:34, address = 0x00007f8dba8b189b
(lldb) b _IO_printf
Breakpoint 4: where = libc.so.6`__printf + 91 at printf.c:34, address = 0x00007f8dba8b189b
(lldb) disassemble -n printf
libc.so.6`__printf at printf.c:30:
   0x7f8dba8b1840:  subq   $216, %rsp

libc.so.6`__printf + 7 at printf.c:30:
   0x7f8dba8b1847:  testb  %al, %al
   0x7f8dba8b1849:  movq   %rsi, 40(%rsp)
   0x7f8dba8b184e:  movq   %rdx, 48(%rsp)
   0x7f8dba8b1853:  movq   %rcx, 56(%rsp)
   0x7f8dba8b1858:  movq   %r8, 64(%rsp)
   0x7f8dba8b185d:  movq   %r9, 72(%rsp)
   0x7f8dba8b1862:  je     0x7f8dba8b189b            ; __printf + 91 at printf.c:34
   0x7f8dba8b1864:  movaps %xmm0, 80(%rsp)
   0x7f8dba8b1869:  movaps %xmm1, 96(%rsp)
   0x7f8dba8b186e:  movaps %xmm2, 112(%rsp)
   0x7f8dba8b1873:  movaps %xmm3, 128(%rsp)
   0x7f8dba8b187b:  movaps %xmm4, 144(%rsp)
   0x7f8dba8b1883:  movaps %xmm5, 160(%rsp)
   0x7f8dba8b188b:  movaps %xmm6, 176(%rsp)
   0x7f8dba8b1893:  movaps %xmm7, 192(%rsp)
   0x7f8dba8b189b:  leaq   224(%rsp), %rax
   0x7f8dba8b18a3:  movq   %rdi, %rsi
   0x7f8dba8b18a6:  leaq   8(%rsp), %rdx
   0x7f8dba8b18ab:  movl   $8, 8(%rsp)
   0x7f8dba8b18b3:  movl   $48, 12(%rsp)
   0x7f8dba8b18bb:  movq   %rax, 16(%rsp)
   0x7f8dba8b18c0:  leaq   32(%rsp), %rax
   0x7f8dba8b18c5:  movq   %rax, 24(%rsp)
   0x7f8dba8b18ca:  movq   3556935(%rip), %rax
   0x7f8dba8b18d1:  movq   (%rax), %rdi
   0x7f8dba8b18d4:  callq  0x7f8dba8a69c0            ; _IO_vfprintf_internal at vfprintf.c:211
   0x7f8dba8b18d9:  addq   $216, %rsp
   0x7f8dba8b18e0:  ret

I'd love to hear feedback on this patch and the split symbol patch overall. I've built it on the Mac using cmake & ninja (won't run locally without debugserver though?). I'm still having issues with xcodebuild randomly failing to link on my Mac, and it seems to rebuild the whole thing when I launch xcodebuild again which takes forever. (This Mac thing has been pretty frustrating.) I've run the entire test suite on Linux, and it says there are some new failure cases but when I run them individually (not through ninja check-lldb) they work. So I'm finding it a bit difficult to verify all this stuff. I'm also gone all next week, so if folks are worried about this large patch it might make sense to wait until early July. I would like to get it looked over and in at some point because the merging is becoming more painful.

Thanks.
 -Mike