[Lldb-commits] [lldb] r184159 - Added a troubleshooting page as a place to add commonly asked questions with solutions.

Greg Clayton gclayton at apple.com
Mon Jun 17 18:01:31 PDT 2013

Author: gclayton
Date: Mon Jun 17 20:01:31 2013
New Revision: 184159

URL: http://llvm.org/viewvc/llvm-project?rev=184159&view=rev
Added a troubleshooting page as a place to add commonly asked questions with solutions. 

The first two questions I have added explanations and answers to are:
- File and line breakpoints are not getting hit
- How do I check if I have debug symbols?

    lldb/trunk/www/troubleshooting.html   (with props)

Modified: lldb/trunk/www/sidebar.incl
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/www/sidebar.incl?rev=184159&r1=184158&r2=184159&view=diff
--- lldb/trunk/www/sidebar.incl (original)
+++ lldb/trunk/www/sidebar.incl Mon Jun 17 20:01:31 2013
@@ -22,6 +22,7 @@
         <li><a href="python-reference.html">Python Reference</a></li>
         <li><a href="scripting.html">Python Example</a></li>
         <li><a href="symbols.html">Symbols on Mac OS X</a></li>
+        <li><a href="troubleshooting.html">Troubleshooting</a></li>
         <li><a href="architecture.html">Architecture</a></li>

Added: lldb/trunk/www/troubleshooting.html
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/www/troubleshooting.html?rev=184159&view=auto
--- lldb/trunk/www/troubleshooting.html (added)
+++ lldb/trunk/www/troubleshooting.html Mon Jun 17 20:01:31 2013
@@ -0,0 +1,89 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+<link href="style.css" rel="stylesheet" type="text/css" />
+<title>LLDB FAQ</title>
+<div class="www_title">
+  Troubleshooting <strong>LLDB</strong>
+<div id="container">
+    <div id="content">
+    <!--#include virtual="sidebar.incl"-->
+        <div class="postfooter"></div>
+            <div id="middle">
+                <div class="post">
+                    <h1 class ="postheader">File and line breakpoints are not getting hit</h1>
+                    <div class="postcontent">
+                        <p>First you must make sure that your source files were compiled with 
+                            debug information. Typically this means passing <code>-g</code> to the
+                            compiler when compiling your source file.
+                        </p>
+                        <p>When setting breakpoints in <b>implementation</b> source files
+                            (.c, cpp, cxx, .m, .mm, etc), LLDB by default will only search for compile units whose filename matches. If your
+                            code does tricky things like using <font color=purple>#include</font> to include source files:
+<code><pre><tt>% <b>cat foo.c</b>
+<font color=purple>#include</font> "bar.c"
+<font color=purple>#include</font> "baz.c"
+                        <p> This will cause breakpoints in "bar.c" to be inlined into the compile unit for "foo.c".
+                            If your code does this, or if your build system combines multiple files in some way such
+                            that breakpoints from one implementation file will be compiled into another implementation file,
+                            you will need to tell LLDB to always search for inlined breakpoint locations
+                            by adding the following line to your <code>~/.lldbinit</code> file:
+                        </p>
+<code><pre><tt>% <b>echo "settings set target.inline-breakpoint-strategy always" >> ~/.lldbinit</b></tt></pre></code>
+                        <p> This tells LLDB to always look in all compile units and search for breakpoint
+                            locations by file and line even if the implementation file doesn't match. Settings breakpoints
+                            in header files always searches all compile units because inline functions are commonly defined
+                            in header files and often cause multiple breakpoints to have source line information that matches
+                            the header files paths.
+                        </p>
+                        <p> If you set a file and line breakpoint using a full path to the source file, like Xcode does when setting a
+                            breakpoint in its GUI on MacOSX when you click in the gutter of the source view, this path must match 
+                            the full paths in the debug information. If the paths mismatch, possibly due to 
+                            passing in a resolved source file path that doesn't match an unresolved path in the debug 
+                            information, this can cause breakpoints to not be resolved. Try setting breakpoints using the file
+                            basaname only.
+                        <p> If you are using an IDE and you move your project in your file system and build again, sometimes doing a 
+                            clean then build will solve the issue.This will fix the issue if some .o files didn't get rebuilt 
+                            after the move as the .o files in the build folder might still contain stale debug information with 
+                            the old source locations.
+                        </p>
+                    </div>
+                <div class="postfooter"></div>
+            </div>
+        </div>
+        <div class="postfooter"></div>
+            <div id="middle">
+                <div class="post">
+                    <h1 class ="postheader">How do I check if I have debug symbols?</h1>
+                    <div class="postcontent">
+                        <p> Checking if a module has any compile units (source files) is a good way to check
+                            if there is debug information in a module:
+(lldb) <b>file /tmp/a.out</b>
+(lldb) <b>image list</b>
+[  0] 71E5A649-8FEF-3887-9CED-D3EF8FC2FD6E 0x0000000100000000 /tmp/a.out 
+      /tmp/a.out.dSYM/Contents/Resources/DWARF/a.out
+[  1] 6900F2BA-DB48-3B78-B668-58FC0CF6BCB8 0x00007fff5fc00000 /usr/lib/dyld 
+(lldb) <b>script lldb.target.module['/tmp/a.out'].GetNumCompileUnits()</b>
+(lldb) <b>script lldb.target.module['/usr/lib/dyld'].GetNumCompileUnits()</b>
+                        <p> Above we can see that "/tmp/a.out" does have a compile unit, and "/usr/lib/dyld" does not.
+                    </div>
+                <div class="postfooter"></div>
+            </div>
+        </div>
+    </div>
\ No newline at end of file

Propchange: lldb/trunk/www/troubleshooting.html
    svn:executable = *

More information about the lldb-commits mailing list