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 <[email protected]<mailto:[email protected]>> Date: Thursday, 20 June, 2013 8:47 PM To: Mike Sartain <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [lldb-dev] breakpoint command On Wed, Jun 19, 2013 at 2:49 PM, Michael Sartain <[email protected]<mailto:[email protected]>> 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 _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
