| <!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"> |
| <head> |
| <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> |
| </head> |
| |
| <body> |
| <div class="www_title"> |
| Troubleshooting <strong>LLDB</strong> |
| </div> |
| |
| <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" |
| ... |
| </tt></pre></code> |
| <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. Setting 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 |
| many header file 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 Mac OS X 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 |
| basename 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: |
| <code><pre><tt> |
| (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> |
| 1 |
| (lldb) <b>script lldb.target.module['/usr/lib/dyld'].GetNumCompileUnits()</b> |
| 0 |
| </tt></pre></code> |
| <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> |
| </div> |
| </body> |
| </html> |