<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Logging can be enabled by a command so you can't do preprocessor tricks to remove logging functions.<div><br></div><div>You can add #ifdef stuff if you just want to debug some things only when manually enabled. </div><div><br></div><div>In the MacOSX build we have 3 defines we defined:</div><div><br></div><div>LLDB_CONFIGURATION_DEBUG</div><div>LLDB_CONFIGURATION_RELEASE</div><div>LLDB_CONFIGURATION_BUILDANDINTEGRATION</div><div><br></div><div>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</div><div><br></div><div>#ifdef LLDB_CONFIGURATION_DEBUG</div><div><br></div><div>to trigger extra logging. </div><div><br></div><div>As far as endianness goes, you shouldn't have to do any of this yourself. We have the lldb_private::<span class="Apple-style-span" style="font-family: Menlo; font-size: 11px; ">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).</span></div><div><span class="Apple-style-span" style="font-family: Menlo; font-size: 11px; "><br></span></div><div><div><div>On Oct 13, 2011, at 9:41 PM, <a href="mailto:dawn@burble.org">dawn@burble.org</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>So I have fixed lldb for Linux (at least on 32-bit - will have to find a<br>64 bit machine to test the 64-bit version).<br><br>But, the patch is gross! <br>So before I embarress myself with a patch, let me first ask:<br><br>1. Is there a way to test "might we be generating logs or not"? I have added<br>some functions and data which are only used when logging is enabled, but I<br>wouldn't want these to get generated in a release build. I really just want some<br>kind of "#ifdef DEBUG" or "#ifdef LOGGING_ENABLED".<br><br>Here's an example from the patch:<br>+#ifdef LOGGING_ENABLED<br>+<br>+// Some functions call other functions (eg. DoWriteMemory calls<br>+// DoReadMemory), so for the purposes of logging, we use a static<br>+// variable to keep track of the API nesting level and only print the<br>+// log at the top-level. FIXME: not thread safe!<br>+//<br>+// This is a bit ugly, but the alternative is to litter the code with<br>+// #ifdefs or hope the compiler is smart enough to optimize all this<br>+// away in an RTM build.<br>+<br>+static int log_nestinglevel;<br>+#define ATTOP_LOG_NESTLEVEL() (log_nestinglevel == 1)<br>+#define INC_LOG_NESTLEVEL() { log_nestinglevel++; } <br>+#define DEC_LOG_NESTLEVEL() { log_nestinglevel--; assert(log_nestinglevel >= 0); } <br>+#else<br>+#define ATTOP_LOG_NESTLEVEL()<br>+#define INC_LOG_NESTLEVEL()<br>+#define DEC_LOG_NESTLEVEL()<br>+#endif<br>+<br><br>2. The code is heavily endian and host platform dependent, which<br>seriously concerns me. I tried to find host-independent representations<br>for the types but came up short. Eg. what type is "void*" on the<br>target?<br><br>Thanks,<br> -Dawn<br><br>On Fri, Oct 07, 2011 at 03:17:32PM -0700, <a href="mailto:dawn@burble.org">dawn@burble.org</a> wrote:<br><blockquote type="cite">With the patch submitted Oct.6,2011 to lldb-commits titled<br></blockquote><blockquote type="cite">"[Lldb-commits] patch to fix Linux build" (still awaiting review)<br></blockquote><blockquote type="cite">the Linux build works. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In addition to setting the PYTHONPATH to find lldb.py, I also needed to add<br></blockquote><blockquote type="cite">$llvm/tools/lldb/examples/synthetic so lldb could find gnu_libstdcpp. Without<br></blockquote><blockquote type="cite">this, you get "ImportError: No module named gnu_libstdcpp" when starting lldb.<br></blockquote><blockquote type="cite">(Please let us know if that's not the intended gnu_libstdcpp module).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">When debugging a simple test case with lldb on Linux (uname -a : Linux<br></blockquote><blockquote type="cite">ack.localdomain 2.6.39.3 #1 SMP Sat Jul 9 21:24:58 PDT 2011 i686 i686 i386<br></blockquote><blockquote type="cite">GNU/Linux) lldb crashes with a segv in pthread_mutex_lock. I've not looked<br></blockquote><blockquote type="cite">into this yet. Here's the stack under gdb:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">ack:~/dev/llvm_svnR137311/tools/lldb$gdb --args ../../Debug+Asserts/bin/lldb ~/dev/test/x GNU gdb (GDB) Fedora (7.2-51.fc14)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Reading symbols from /home/dawn/dev/llvm_svnR137311/Debug+Asserts/bin/lldb...done.<br></blockquote><blockquote type="cite">(gdb) r<br></blockquote><blockquote type="cite">Starting program: /home/dawn/dev/llvm_svnR137311/Debug+Asserts/bin/lldb /home/dawn/dev/test/x<br></blockquote><blockquote type="cite">[Thread debugging using libthread_db enabled]<br></blockquote><blockquote type="cite">[New Thread 0xb46e2b70 (LWP 10309)]<br></blockquote><blockquote type="cite">[New Thread 0xb3ee1b70 (LWP 10310)]<br></blockquote><blockquote type="cite">[New Thread 0xb36e0b70 (LWP 10311)]<br></blockquote><blockquote type="cite">[New Thread 0xb2edfb70 (LWP 10312)]<br></blockquote><blockquote type="cite">Current executable set to '/home/dawn/dev/test/x' (i386).<br></blockquote><blockquote type="cite">(lldb) r<br></blockquote><blockquote type="cite">[New Thread 0xb22ffb70 (LWP 10313)]<br></blockquote><blockquote type="cite">Detaching after fork from child process 10314.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Program received signal SIGSEGV, Segmentation fault.<br></blockquote><blockquote type="cite">[Switching to Thread 0xb22ffb70 (LWP 10313)]<br></blockquote><blockquote type="cite">0x49d6cf4d in pthread_mutex_lock () from /lib/libpthread.so.0<br></blockquote><blockquote type="cite">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<br></blockquote><blockquote type="cite">(gdb) bt<br></blockquote><blockquote type="cite">#0 0x49d6cf4d in pthread_mutex_lock () from /lib/libpthread.so.0<br></blockquote><blockquote type="cite">#1 0xb620e18f in lldb_private::Mutex::Lock (mutex_ptr=0x14) at Mutex.cpp:190<br></blockquote><blockquote type="cite">#2 0xb620ddd2 in lldb_private::Mutex::Locker::Locker (this=0xb22febe4, m=...) at Mutex.cpp:46<br></blockquote><blockquote type="cite">#3 0xb6c710ec in ProcessMonitor::DoOperation (this=0x0, op=0xb22fec1c) at ProcessMonitor.cpp:1298<br></blockquote><blockquote type="cite">#4 0xb6c712d6 in ProcessMonitor::ReadRegisterValue (this=0x0, offset=60, value=...)<br></blockquote><blockquote type="cite"> at ProcessMonitor.cpp:1343<br></blockquote><blockquote type="cite">#5 0xb6c721c0 in RegisterContextLinux_i386::ReadRegister (this=0x8170ee8, reg_info=0xb7f56294, <br></blockquote><blockquote type="cite"> value=...) at RegisterContextLinux_i386.cpp:419<br></blockquote><blockquote type="cite">#6 0xb63c9599 in lldb_private::RegisterContext::ReadRegisterAsUnsigned (this=0x8170ee8, <br></blockquote><blockquote type="cite"> reg_info=0xb7f56294, fail_value=18446744073709551615) at RegisterContext.cpp:163<br></blockquote><blockquote type="cite">#7 0xb63c953c in lldb_private::RegisterContext::ReadRegisterAsUnsigned (this=0x8170ee8, reg=7, <br></blockquote><blockquote type="cite"> fail_value=18446744073709551615) at RegisterContext.cpp:153<br></blockquote><blockquote type="cite">#8 0xb63c92c7 in lldb_private::RegisterContext::GetSP (this=0x8170ee8, <br></blockquote><blockquote type="cite"> fail_value=18446744073709551615) at RegisterContext.cpp:110<br></blockquote><blockquote type="cite">#9 0xb63d210f in lldb_private::StackFrameList::GetFrameAtIndex (this=0x8170e98, idx=0)<br></blockquote><blockquote type="cite"> at StackFrameList.cpp:273<br></blockquote><blockquote type="cite">#10 0xb63d284b in lldb_private::StackFrameList::SetDefaultFileAndLineToSelectedFrame (<br></blockquote><blockquote type="cite"> this=0x8170e98) at StackFrameList.cpp:406<br></blockquote><blockquote type="cite">[...]<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So clearly the Linux port needs more work, and I'm not sure if I'm going to be<br></blockquote><blockquote type="cite">able to give it the attention it needs.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-Dawn<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Mon, Sep 26, 2011 at 03:46:18PM -0700, <a href="mailto:dawn@burble.org">dawn@burble.org</a> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I have lldb rev 140572.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I followed the instructions here: <a href="http://lldb.llvm.org/build.html">http://lldb.llvm.org/build.html</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and updated my llvm and clang trees to the documented revision:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> $grep -m 1 llvm_revision $lldb/scripts/build-llvm.pl <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> our $llvm_revision = "137311";<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">When I build, I get:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">[...]<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">llvm[2]: Compiling ClangUserExpression.cpp for Debug+Asserts build<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In file included from ClangUserExpression.cpp:31:0:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">/home/dawn/dev/llvm_svn/tools/lldb/source/Expression/../../include/lldb/Expression/ExpressionSourceCode.h:13:31:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">fatal error: lldb-enumerations.h: No such file or directory<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">compilation terminated.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">[...]<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Please help,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Thanks,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-Dawn<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">lldb-dev mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br></blockquote></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">lldb-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br></blockquote><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br></blockquote>_______________________________________________<br>lldb-dev mailing list<br><a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev<br></div></blockquote></div><br></div></body></html>