On May 8, 2013, at 11:41 AM, "Malea, Daniel" <[email protected]> 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" <[email protected]> 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 >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
