[lldb-dev] Linux command line issues

[Malea, Daniel]

Hi Greg! I have not seen the exact issue you're referring to with the
command output showing up on the same line. Which version of libedit are
you using? When I run "apt-cache policy libedit-dev" I see:

libedit-dev:
  Installed: 2.11-20080614-5
  Candidate: 2.11-20080614-5
  Version table:
 *** 2.11-20080614-5 0
        500 http://us.archive.ubuntu.com/ubuntu/ quantal/main amd64
Packages
        100 /var/lib/dpkg/status



Note that I have seen reports of other bugs that seem related to lib edit
-- for example, the "(lldb)" prompt disappearing after running commands.

What is your concern with the malloc breakpoint? I do see the same thing:
__libc_malloc is the actual symbol of the 'malloc' function. This might
have something to do with the "GNU Indirect" calling convention, but I'm
not sure -- maybe Matt knows the details of how those two symbols relate
to each other?



Cheers,
Dan

On 2013-05-08 2:12 PM, "Greg Clayton" <gclayton at apple.com> wrote:

>I was finally able to build LLDB on my Ubuntu box. I needed to disable
>debug symbols otherwise I was unable to link clang.
>
>I tried out lldb:
>
>./lldb
>(lldb) file /bin/ls
>Current executable set to '/bin/ls' (x86_64).
>(lldb) b malloc
>Breakpoint 1: no locations (pending).
>WARNING:  Unable to resolve breakpoint to any actual locations.
>(lldb) r
>Process 6985 launched: '/bin/ls' (x86_64)
>1 location added to breakpoint 1
>1 location added to breakpoint 1
>Process 6985 stopped
>* thread #1: tid = 0x1b49, 0x00007ff63da9ff50 libc.so.6`__libc_malloc,
>stop reason = breakpoint 1.1
>    frame #0: 0x00007ff63da9ff50 libc.so.6`__libc_malloc
>libc.so.6`__libc_malloc:
>-> 0x7ff63da9ff50:  movq   %r12, -16(%rsp)
>
>libc.so.6`malloc + 5:
>   0x7ff63da9ff55:  movq   %rbx, -32(%rsp)
>   0x7ff63da9ff5a:  movq   %rdi, %r12
>   0x7ff63da9ff5d:  movq   %rbp, -24(%rsp)
>
>
>So this looks bad. We have a symbol __libc_malloc which purports to be
>just the first instruction of "malloc"? I need to look into the symbol
>tables and see what is going on.
>
>
>
>(lldb) bt
>* thread #1: tid = 0x1b49, 0x00007ff63da9ff50 libc.so.6`__libc_malloc,
>stop reason = breakpoint 1.1
>    frame #0: 0x00007ff63da9ff50 libc.so.6`__libc_malloc
>(lldb) cProcess 6985 resuming
>
>
>Note the "Process 6985 resuming" is on the same line as the "(lldb) c"?
>Is anyone else seeing this kind of thing?
>
>
>
>
>
>
>Process 6985 stopped
>* thread #1: tid = 0x1b49, 0x00007ff63da9ff50 libc.so.6`__libc_malloc,
>stop reason = breakpoint 1.1
>    frame #0: 0x00007ff63da9ff50 libc.so.6`__libc_malloc
>libc.so.6`__libc_malloc:
>-> 0x7ff63da9ff50:  movq   %r12, -16(%rsp)
>
>libc.so.6`malloc + 5:
>   0x7ff63da9ff55:  movq   %rbx, -32(%rsp)
>   0x7ff63da9ff5a:  movq   %rdi, %r12
>   0x7ff63da9ff5d:  movq   %rbp, -24(%rsp)
>(lldb) bt* thread #1: tid = 0x1b49, 0x00007ff63da9ff50
>libc.so.6`__libc_malloc, stop reason = breakpoint 1.1
>    frame #0: 0x00007ff63da9ff50 libc.so.6`__libc_malloc
>    frame #1: 0x00007ff63da4ab7f libc.so.6
>    frame #2: 0x00007ff63da49df3 libc.so.6
>    frame #3: 0x00007ff63da4965a libc.so.6`setlocale + 650
>
>
>Again, is anyone seeing commands being entered appear on the same line as
>command output??
>
>Overall the editline interface seems to be misbehaving on a regular
>basis. Any non MacOSX users, please chime in and let me know if this is a
>common issue?
>
>Greg
>
>
>_______________________________________________
>lldb-dev mailing list
>lldb-dev at cs.uiuc.edu
>http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev