1Troubleshooting 2=============== 3 4File and Line Breakpoints Are Not Getting Hit 5--------------------------------------------- 6 7First you must make sure that your source files were compiled with debug 8information. Typically this means passing -g to the compiler when compiling 9your 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 filename 13matches. If your code does tricky things like using #include to include source 14files: 15 16:: 17 18 $ cat foo.c 19 #include "bar.c" 20 #include "baz.c" 21 ... 22 23This will cause breakpoints in "bar.c" to be inlined into the compile unit for 24"foo.c". If your code does this, or if your build system combines multiple 25files in some way such that breakpoints from one implementation file will be 26compiled into another implementation file, you will need to tell LLDB to always 27search for inlined breakpoint locations by adding the following line to your 28~/.lldbinit file: 29 30:: 31 32 $ echo "settings set target.inline-breakpoint-strategy always" >> ~/.lldbinit 33 34This tells LLDB to always look in all compile units and search for breakpoint 35locations by file and line even if the implementation file doesn't match. 36Setting breakpoints in header files always searches all compile units because 37inline functions are commonly defined in header files and often cause multiple 38breakpoints to have source line information that matches many header file 39paths. 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 click 43in the gutter of the source view, this path must match the full paths in the 44debug information. If the paths mismatch, possibly due to passing in a resolved 45source file path that doesn't match an unresolved path in the debug 46information, this can cause breakpoints to not be resolved. Try setting 47breakpoints using the file basename only. 48 49If you are using an IDE and you move your project in your file system and build 50again, sometimes doing a clean then build will solve the issue.This will fix 51the issue if some .o files didn't get rebuilt after the move as the .o files in 52the build folder might still contain stale debug information with the old 53source 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 to 59check if there is debug information in a module: 60 61:: 62 63 (lldb) file /tmp/a.out 64 (lldb) image list 65 [ 0] 71E5A649-8FEF-3887-9CED-D3EF8FC2FD6E 0x0000000100000000 /tmp/a.out 66 /tmp/a.out.dSYM/Contents/Resources/DWARF/a.out 67 [ 1] 6900F2BA-DB48-3B78-B668-58FC0CF6BCB8 0x00007fff5fc00000 /usr/lib/dyld 68 .... 69 (lldb) script lldb.target.module['/tmp/a.out'].GetNumCompileUnits() 70 1 71 (lldb) script lldb.target.module['/usr/lib/dyld'].GetNumCompileUnits() 72 0 73 74Above we can see that "/tmp/a.out" does have a compile unit, and 75"/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) script 82 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.fullpath 86 /tmp/main.c 87 /tmp/foo.c 88 /tmp/bar.c 89 >>> 90 91This can help to show the actual full path to the source files. Sometimes IDEs 92will set breakpoints by full paths where the path doesn't match the full path 93in the debug info and this can cause LLDB to not resolve breakpoints. You can 94use the breakpoint list command with the --verbose option to see the full paths 95for any source file and line breakpoints that the IDE set using: 96 97:: 98 99 (lldb) breakpoint list --verbose 100