[lldb-dev] Disassembling with no function bounds

[Zachary Turner]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150121/2f5b32e2/attachment.html>