100 lines · plain
1Troubleshooting2===============3 4File and Line Breakpoints Are Not Getting Hit5---------------------------------------------6 7First you must make sure that your source files were compiled with debug8information. Typically this means passing -g to the compiler when compiling9your source file.10 11When setting breakpoints in implementation source files (.c, cpp, cxx, .m, .mm,12etc), LLDB by default will only search for compile units whose filename13matches. If your code does tricky things like using #include to include source14files:15 16::17 18 $ cat foo.c19 #include "bar.c"20 #include "baz.c"21 ...22 23This will cause breakpoints in "bar.c" to be inlined into the compile unit for24"foo.c". If your code does this, or if your build system combines multiple25files in some way such that breakpoints from one implementation file will be26compiled into another implementation file, you will need to tell LLDB to always27search for inlined breakpoint locations by adding the following line to your28~/.lldbinit file:29 30::31 32 $ echo "settings set target.inline-breakpoint-strategy always" >> ~/.lldbinit33 34This tells LLDB to always look in all compile units and search for breakpoint35locations by file and line even if the implementation file doesn't match.36Setting breakpoints in header files always searches all compile units because37inline functions are commonly defined in header files and often cause multiple38breakpoints to have source line information that matches many header file39paths.40 41If you set a file and line breakpoint using a full path to the source file,42like Xcode does when setting a breakpoint in its GUI on macOS when you click43in the gutter of the source view, this path must match the full paths in the44debug information. If the paths mismatch, possibly due to passing in a resolved45source file path that doesn't match an unresolved path in the debug46information, this can cause breakpoints to not be resolved. Try setting47breakpoints using the file basename only.48 49If you are using an IDE and you move your project in your file system and build50again, sometimes doing a clean then build will solve the issue.This will fix51the issue if some .o files didn't get rebuilt after the move as the .o files in52the build folder might still contain stale debug information with the old53source locations.54 55How Do I Check If I Have Debug Symbols?56---------------------------------------57 58Checking if a module has any compile units (source files) is a good way to59check if there is debug information in a module:60 61::62 63 (lldb) file /tmp/a.out64 (lldb) image list65 [ 0] 71E5A649-8FEF-3887-9CED-D3EF8FC2FD6E 0x0000000100000000 /tmp/a.out66 /tmp/a.out.dSYM/Contents/Resources/DWARF/a.out67 [ 1] 6900F2BA-DB48-3B78-B668-58FC0CF6BCB8 0x00007fff5fc00000 /usr/lib/dyld68 ....69 (lldb) script lldb.target.module['/tmp/a.out'].GetNumCompileUnits()70 171 (lldb) script lldb.target.module['/usr/lib/dyld'].GetNumCompileUnits()72 073 74Above we can see that "/tmp/a.out" does have a compile unit, and75"/usr/lib/dyld" does not.76 77We can also list the full paths to all compile units for a module using python:78 79::80 81 (lldb) script82 Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.83 >>> m = lldb.target.module['a.out']84 >>> for i in range(m.GetNumCompileUnits()):85 ... cu = m.GetCompileUnitAtIndex(i).file.fullpath86 /tmp/main.c87 /tmp/foo.c88 /tmp/bar.c89 >>>90 91This can help to show the actual full path to the source files. Sometimes IDEs92will set breakpoints by full paths where the path doesn't match the full path93in the debug info and this can cause LLDB to not resolve breakpoints. You can94use the breakpoint list command with the --verbose option to see the full paths95for any source file and line breakpoints that the IDE set using:96 97::98 99 (lldb) breakpoint list --verbose100