build fails on linux

I have lldb rev 140572.

I followed the instructions here:

and updated my llvm and clang trees to the documented revision:
    $grep -m 1 llvm_revision $lldb/scripts/
    our $llvm_revision = "137311";

When I build, I get:
llvm[2]: Compiling ClangUserExpression.cpp for Debug+Asserts build
In file included from ClangUserExpression.cpp:31:0:
fatal error: lldb-enumerations.h: No such file or directory
compilation terminated.

Please help,


I just committed r140577, which should resolve your problem.


Thank you! That got me a little further. Now I get:

make[3]: Entering directory
llvm[3]: Compiling ProcessLinux.cpp for Debug+Asserts build
ProcessLinux.cpp: In static member function 'static
ProcessLinux.cpp:36:45: error: cannot allocate an object of abstract
type 'ProcessLinux'
ProcessLinux.h:27:1: note: because the following virtual functions are
pure within 'ProcessLinux':
note: virtual uint32_t
ProcessLinux.cpp: In member function 'virtual lldb::addr_t
ProcessLinux::DoAllocateMemory(size_t, uint32_t, lldb_private::Error&)':
ProcessLinux.cpp:375:145: warning: ISO C++ does not support the 'z'
gnu_printf length modifier
ProcessLinux.cpp: In static member function 'static
ProcessLinux.cpp:37:1: warning: control reaches end of non-void function
/bin/rm: cannot remove
No such file or directory
make[3]: ***
Error 1

I tried to fix it by copying the UpdateThreadList function from
MacOSX-Kernel/ProcessKDP.cpp (and fixing the identifiers), but that
just led me into a different set of errors.

Thanks in advance,

You might need to add any missing pure virtual functions that are in Process.h into the ProcessLinux.h/cpp, even if they just return errors or zero values.

Thanks - I added a UpdateThreadList that returns 0.

The next error I run into is:

    llvm[3]: Compiling ProcessLinux.cpp for Debug+Asserts build
    ProcessLinux.cpp: In member function 'virtual lldb::addr_t
    ProcessLinux::DoAllocateMemory(size_t, uint32_t, lldb_private::Error&)':
    ProcessLinux.cpp:375:145: warning: ISO C++ does not support the 'z'
    gnu_printf length modifier
    llvm[3]: Compiling ProcessMessage.cpp for Debug+Asserts build
    llvm[3]: Compiling ProcessMonitor.cpp for Debug+Asserts build
    ProcessMonitor.cpp: In member function 'virtual void
    ProcessMonitor.cpp:250:19: error: ambiguous overload for 'operator=' in
    '((ReadRegOperation*)this)->ReadRegOperation::m_value = data'
    note: candidates are: void
  note: void
  note: void

Which I fixed in Linux/ProcessMonitor.cpp line 244 with:
  uint32_t data = ptrace(PTRACE_PEEKUSER, pid, m_offset, NULL);

Then I run into:
    llvm[3]: Compiling DynamicLoaderLinuxDYLD.cpp for Debug+Asserts build
    DynamicLoaderLinuxDYLD.cpp: In member function 'virtual void
    DynamicLoaderLinuxDYLD.cpp:115:21: error: 'class lldb::ModuleSP' has no
    member named 'empty'
    DynamicLoaderLinuxDYLD.cpp: In member function 'virtual void
    DynamicLoaderLinuxDYLD.cpp:135:21: error: 'class lldb::ModuleSP' has no
    member named 'empty'
    DynamicLoaderLinuxDYLD.cpp: In member function 'void
    DynamicLoaderLinuxDYLD.cpp:267:28: error: 'class lldb::ModuleSP' has no
    member named 'empty'
    DynamicLoaderLinuxDYLD.cpp:283:28: error: 'class lldb::ModuleSP' has no
    member named 'empty'
    DynamicLoaderLinuxDYLD.cpp: In member function 'void
    DynamicLoaderLinuxDYLD.cpp:358:24: error: 'class lldb::ModuleSP' has no
    member named 'empty'
    /bin/rm: cannot remove
    No such file or directory
    make[3]: ***
    Error 1
    make[3]: Leaving directory

I gather Linux isn't actively supported as a platform?
Should I give up and go back to trying to get things to build on
Mac OS X again? There I get the gcc 4.2.1 ambiguity errors (see
previous thread).

Thanks again,

With the patch submitted Oct.6,2011 to lldb-commits titled
"[Lldb-commits] patch to fix Linux build" (still awaiting review)
the Linux build works.

In addition to setting the PYTHONPATH to find, I also needed to add
$llvm/tools/lldb/examples/synthetic so lldb could find gnu_libstdcpp. Without
this, you get "ImportError: No module named gnu_libstdcpp" when starting lldb.
(Please let us know if that's not the intended gnu_libstdcpp module).

When debugging a simple test case with lldb on Linux (uname -a : Linux
ack.localdomain #1 SMP Sat Jul 9 21:24:58 PDT 2011 i686 i686 i386
GNU/Linux) lldb crashes with a segv in pthread_mutex_lock. I've not looked
into this yet. Here's the stack under gdb:

ack:~/dev/llvm_svnR137311/tools/lldb$gdb --args ../../Debug+Asserts/bin/lldb ~/dev/test/x GNU gdb (GDB) Fedora (7.2-51.fc14)

Reading symbols from /home/dawn/dev/llvm_svnR137311/Debug+Asserts/bin/lldb...done.
(gdb) r
Starting program: /home/dawn/dev/llvm_svnR137311/Debug+Asserts/bin/lldb /home/dawn/dev/test/x
[Thread debugging using libthread_db enabled]
[New Thread 0xb46e2b70 (LWP 10309)]
[New Thread 0xb3ee1b70 (LWP 10310)]
[New Thread 0xb36e0b70 (LWP 10311)]
[New Thread 0xb2edfb70 (LWP 10312)]
Current executable set to '/home/dawn/dev/test/x' (i386).
(lldb) r
[New Thread 0xb22ffb70 (LWP 10313)]
Detaching after fork from child process 10314.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb22ffb70 (LWP 10313)]
0x49d6cf4d in pthread_mutex_lock () from /lib/
Missing separate debuginfos, use: debuginfo-install glibc-2.13-2.i686 keyutils-libs-1.2-6.fc12.i686 krb5-libs-1.8.4-2.fc14.i686 libcom_err-1.41.12-6.fc14.i686 libedit-3.0-3.20090923cvs.fc14.i686 libgcc-4.5.1-4.fc14.i686 libselinux-2.0.96-6.fc14.1.i686 libstdc++-4.5.1-4.fc14.i686 ncurses-libs-5.7-9.20100703.fc14.i686 openssl-1.0.0e-1.fc14.i686 python-2.7-8.fc14.1.i686 python-libs-2.7-8.fc14.1.i686 readline-6.1-2.fc14.i386 zlib-1.2.5-2.fc14.i686
(gdb) bt
#0 0x49d6cf4d in pthread_mutex_lock () from /lib/
#1 0xb620e18f in lldb_private::Mutex::Lock (mutex_ptr=0x14) at Mutex.cpp:190
#2 0xb620ddd2 in lldb_private::Mutex::Locker::Locker (this=0xb22febe4, m=...) at Mutex.cpp:46
#3 0xb6c710ec in ProcessMonitor::DoOperation (this=0x0, op=0xb22fec1c) at ProcessMonitor.cpp:1298
#4 0xb6c712d6 in ProcessMonitor::ReadRegisterValue (this=0x0, offset=60, value=...)
    at ProcessMonitor.cpp:1343
#5 0xb6c721c0 in RegisterContextLinux_i386::ReadRegister (this=0x8170ee8, reg_info=0xb7f56294,
    value=...) at RegisterContextLinux_i386.cpp:419
#6 0xb63c9599 in lldb_private::RegisterContext::ReadRegisterAsUnsigned (this=0x8170ee8,
    reg_info=0xb7f56294, fail_value=18446744073709551615) at RegisterContext.cpp:163
#7 0xb63c953c in lldb_private::RegisterContext::ReadRegisterAsUnsigned (this=0x8170ee8, reg=7,
    fail_value=18446744073709551615) at RegisterContext.cpp:153
#8 0xb63c92c7 in lldb_private::RegisterContext::GetSP (this=0x8170ee8,
    fail_value=18446744073709551615) at RegisterContext.cpp:110
#9 0xb63d210f in lldb_private::StackFrameList::GetFrameAtIndex (this=0x8170e98, idx=0)
    at StackFrameList.cpp:273
#10 0xb63d284b in lldb_private::StackFrameList::SetDefaultFileAndLineToSelectedFrame (
    this=0x8170e98) at StackFrameList.cpp:406

So clearly the Linux port needs more work, and I'm not sure if I'm going to be
able to give it the attention it needs.



Sean Callanan just updated to a very very recent clang. Please checkout LLDB revision 141444 or later and resubmit the patch. We are going to try and keep more up to date with the latest LLVM/Clang, but we don't suggest anyone else try to do the merges with LLVM because, even though things might build, there are often times test suite errors that occur due to the compiler changes.

Greg Clayton

Thank you. I have resubmitted the patch to lldb-commits.

So I have fixed lldb for Linux (at least on 32-bit - will have to find a
64 bit machine to test the 64-bit version).

But, the patch is gross!
So before I embarress myself with a patch, let me first ask:

1. Is there a way to test "might we be generating logs or not"? I have added
some functions and data which are only used when logging is enabled, but I
wouldn't want these to get generated in a release build. I really just want some
kind of "#ifdef DEBUG" or "#ifdef LOGGING_ENABLED".

Here's an example from the patch:

Logging can be enabled by a command so you can’t do preprocessor tricks to remove logging functions.

You can add #ifdef stuff if you just want to debug some things only when manually enabled.

In the MacOSX build we have 3 defines we defined:


The first two are for local builds where you are testing and debugging. The last one is for builds that are optimized and are for submission. You could have the linux build start to enable these somehow and use a


to trigger extra logging.

As far as endianness goes, you shouldn’t have to do any of this yourself. We have the lldb_private::DataExtractor class which should be used to extract data. It can handle all of your data dumping needs (see the “memory read” command). You give it a byte order (big endian, little endian, which you can get from your Target arch spec) and you give if the address byte size (size in bytes of a pointer as well).