Linux command line issues

Subprojects LLDB
1

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

2

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 Index of /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

3

I checked the libc.so.6 symbol table and malloc isn't an indirect function. However, 'malloc' and '__libc_malloc' have the same entries for address and size so it looks like they are the same.

In the past, I have seen the editline issues Greg mentions though I didn't see it consistently in all cases.

Matt

4

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 Index of /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 Index of /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)

5

Agreed. Will file a bugzilla accordingly.