[lldb-dev] Disassembling with no function bounds

[jingham at apple.com]

The way this is supposed to work in lldb is that the "repeat command" that disassemble registers when you run the disassemble command should do "disassemble from the last instruction disassembled".  So you should just hit return on the empty line to keep disassembling.  It is a general feature that any lldb command can tell the command interpreter what "do me again" - i.e. return on a blank line - should do.  Most commands repeat themselves, some commands like "run" don't auto-repeat because that's generally not what you want, and "source list" does the same trick disassemble was SUPPOSED to do.

But with TOT lldb, something seems to have broken that:

(lldb) dis -s 0x0000000100019b07
->  0x100019b07 <main+55>: movq   %rax, %rdi
    0x100019b0a <main+58>: movb   $0x0, %al
    0x100019b0c <main+60>: callq  0x10001e28a               ; symbol stub for: NSLog
    0x100019b11 <main+65>: leaq   0xa790(%rip), %rcx        ; @Sketch.__TEXT.__ustring + 0
    0x100019b18 <main+72>: movb   $0x0, -0x101(%rbp)
    0x100019b1f <main+79>: movq   %rcx, -0x110(%rbp)
(lldb) 
->  0x100019b07 <main+55>: movq   %rax, %rdi
    0x100019b0a <main+58>: movb   $0x0, %al
    0x100019b0c <main+60>: callq  0x10001e28a               ; symbol stub for: NSLog
    0x100019b11 <main+65>: leaq   0xa790(%rip), %rcx        ; @Sketch.__TEXT.__ustring + 0
    0x100019b18 <main+72>: movb   $0x0, -0x101(%rbp)
    0x100019b1f <main+79>: movq   %rcx, -0x110(%rbp)

Grrr....

Jim


> On Jan 21, 2015, at 2:20 PM, Zachary Turner <zturner at google.com> wrote:
> 
> I tried -c and that didn't work at all (may be a Windows bug which I have to look into).
> 
> I guess what I'm wondering is: Why do I have to care about function bounds at all?  Here's some output from my favorite Windows debugger.  "u main" means unassemble main, and "u" with no arguments means "keep unassembling from the address where the last unassemble stopped".
> 
> 0:000> u main
> expr_test_cl!main [d:\testexe\expr_test.cpp @ 23]:
> 002e1050 55              push    ebp
> 002e1051 8bec            mov     ebp,esp
> 002e1053 68883c3000      push    offset expr_test_cl!__xt_z+0x144 (00303c88)
> 002e1058 e8d0000000      call    expr_test_cl!printf (002e112d)
> 002e105d 83c404          add     esp,4
> 002e1060 68983c3000      push    offset expr_test_cl!__xt_z+0x154 (00303c98)
> 002e1065 e8c3000000      call    expr_test_cl!printf (002e112d)
> 002e106a 83c404          add     esp,4
> 0:000> u
> expr_test_cl!main+0x1d [d:\testexe\expr_test.cpp @ 26]:
> 002e106d 68a83c3000      push    offset expr_test_cl!__xt_z+0x164 (00303ca8)
> 002e1072 e8b6000000      call    expr_test_cl!printf (002e112d)
> 002e1077 83c404          add     esp,4
> 002e107a b801000000      mov     eax,1
> 002e107f 5d              pop     ebp
> 002e1080 c3              ret
> 002e1081 cc              int     3
> 002e1082 cc              int     3
> 0:000> u
> expr_test_cl!main+0x33:
> 002e1083 cc              int     3
> 002e1084 cc              int     3
> 002e1085 cc              int     3
> 002e1086 cc              int     3
> 002e1087 cc              int     3
> 002e1088 cc              int     3
> 002e1089 cc              int     3
> 002e108a cc              int     3
> 0:000> u
> expr_test_cl!main+0x3b:
> 002e108b cc              int     3
> 002e108c cc              int     3
> 002e108d cc              int     3
> 002e108e cc              int     3
> 002e108f cc              int     3
> 002e1090 cc              int     3
> 002e1091 cc              int     3
> 002e1092 cc              int     3
> 0:000> u
> expr_test_cl!main+0x43:
> 002e1093 cc              int     3
> 002e1094 cc              int     3
> expr_test_cl!_get_printf_count_output [f:\dd\vctools\crt\crtw32\stdio\printf.c @ 166]:
> 002e1095 8b0d00b43000    mov     ecx,dword ptr [expr_test_cl!__security_cookie (0030b400)]
> 002e109b 33c0            xor     eax,eax
> 002e109d 83c901          or      ecx,1
> 002e10a0 390d40c53000    cmp     dword ptr [expr_test_cl!__enable_percent_n (0030c540)],ecx
> 002e10a6 0f94c0          sete    al
> 002e10a9 c3              ret
> 0:000> u
> expr_test_cl!_printf_l [f:\dd\vctools\crt\crtw32\stdio\printf.c @ 79]:
> 002e10aa 55              push    ebp
> 002e10ab 8bec            mov     ebp,esp
> 002e10ad 8d4510          lea     eax,[ebp+10h]
> 002e10b0 50              push    eax
> 002e10b1 ff750c          push    dword ptr [ebp+0Ch]
> 002e10b4 ff7508          push    dword ptr [ebp+8]
> 002e10b7 e879060000      call    expr_test_cl!_vprintf_l (002e1735)
> 002e10bc 83c40c          add     esp,0Ch
> 
> Note that there's no knowledge of function bounds.  It just goes.  Is it possible to do something like this in LLDB?  Or if not, can I implement it?
> 
> 
> On Wed Jan 21 2015 at 2:11:03 PM Ed Maste <emaste at freebsd.org> wrote:
> On 21 January 2015 at 16:57, Zachary Turner <zturner at google.com> wrote:
> >
> > Is there any way to work around this restriction?  It seems like it
> > shouldn't matter what the bounds of the function are, or if there's even a
> > function at this address at all.  As long as there's code.
> 
> You should be able to use a combination of -s start address / -e end
> address / -c instruction count.
> 
> Perhaps we could disassemble a small number of instructions starting
> from the provided address if -a is given an address outside of a
> function.
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev