[lldb-dev] Linux command line issues

[Greg Clayton]

On May 8, 2013, at 11:41 AM, "Malea, Daniel" <daniel.malea at intel.com> wrote:

> 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


apt-cache policy libedit-dev
libedit-dev:
  Installed: 2.11-20080614-3ubuntu2
  Candidate: 2.11-20080614-3ubuntu2
  Version table:
 *** 2.11-20080614-3ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/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.

I saw this as well in my limited testing.

> 
> 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?

My concern is that we present the most useful symbol to the user when we stop. The disassembly is broken up as a result of the __libc_malloc symbol. I am guessing this symbol __libc_malloc has a size of zero. When looking up a symbol by address, we are finding "__libc_malloc" first instead of just "malloc". We should be picking "malloc" first if it has a valid byte size.

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)
> 

> 
> 
> 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
>