[lldb-dev] build fails on linux

Greg Clayton gclayton at apple.com
Thu Oct 13 23:14:14 PDT 2011 

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:

LLDB_CONFIGURATION_DEBUG
LLDB_CONFIGURATION_RELEASE
LLDB_CONFIGURATION_BUILDANDINTEGRATION

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

#ifdef LLDB_CONFIGURATION_DEBUG

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

On Oct 13, 2011, at 9:41 PM, dawn at burble.org wrote:

> 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:
> +#ifdef LOGGING_ENABLED
> +
> +// Some functions call other functions (eg. DoWriteMemory calls
> +// DoReadMemory), so for the purposes of logging, we use a static
> +// variable to keep track of the API nesting level and only print the
> +// log at the top-level.  FIXME: not thread safe!
> +//
> +// This is a bit ugly, but the alternative is to litter the code with
> +// #ifdefs or hope the compiler is smart enough to optimize all this
> +// away in an RTM build.
> +
> +static int log_nestinglevel;
> +#define ATTOP_LOG_NESTLEVEL() (log_nestinglevel == 1)
> +#define INC_LOG_NESTLEVEL() { log_nestinglevel++; } 
> +#define DEC_LOG_NESTLEVEL() { log_nestinglevel--; assert(log_nestinglevel >= 0); } 
> +#else
> +#define ATTOP_LOG_NESTLEVEL()
> +#define INC_LOG_NESTLEVEL()
> +#define DEC_LOG_NESTLEVEL()
> +#endif
> +
> 
> 2.  The code is heavily endian and host platform dependent, which
> seriously concerns me.  I tried to find host-independent representations
> for the types but came up short.  Eg.  what type is "void*" on the
> target?
> 
> Thanks,
>    -Dawn
> 
> On Fri, Oct 07, 2011 at 03:17:32PM -0700, dawn at burble.org wrote:
>> 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 lldb.py, 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 2.6.39.3 #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/libpthread.so.0
>> 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/libpthread.so.0
>> #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.
>> 
>> -Dawn
>> 
>> 
>> On Mon, Sep 26, 2011 at 03:46:18PM -0700, dawn at burble.org wrote:
>>> 
>>> I have lldb rev 140572.
>>> 
>>> I followed the instructions here: http://lldb.llvm.org/build.html
>>> 
>>> and updated my llvm and clang trees to the documented revision:
>>>    $grep -m 1 llvm_revision $lldb/scripts/build-llvm.pl 
>>>    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:
>>> /home/dawn/dev/llvm_svn/tools/lldb/source/Expression/../../include/lldb/Expression/ExpressionSourceCode.h:13:31:
>>> fatal error: lldb-enumerations.h: No such file or directory
>>> compilation terminated.
>>> [...]
>>> 
>>> Please help,
>>> Thanks,
>>> -Dawn
>>> 
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20111013/8b0a78bf/attachment.html>

More information about the lldb-dev mailing list