lldb/docs/use/troubleshooting.rst

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