Understanding Large Codebases

From 360iDev 2019

Find the sample “project” (GitHawk fork) here.

Slides are available here.


Some tips for starting out on a new project


  • Use the Symbol Navigator to navigate through a project
  • Use the Call Hierarchy to understand flow through project
  • Use ⌃⌘J to jump to a definition in a project


command source ~/.lldb-scripts/sounds/breakpoints.txt
  • Auto-continuing sound breakpoints tagged with a name (contents of breakpoints.txt above)
breakpoint set -n "-[UIViewController dealloc]" -C "platform shell afplay /System/Library/Sounds/Submarine.aiff" --auto-continue true -d -N audio
  • Use common scripts across projects
  • Facebook’s Chisel commands and helpers

  • apropos command to search commands and help text
  • log enable -f /tmp/log.txt lldb all enable logging to a file
  • value.GetError().GetCString() retrieve string from error in SBValue (using LLDB’s Python APIs)



What can you do to make the onboarding process easier for new developers?


  • Documentation mini map
  • Hold ⌘ to show symbols


  • Add a file to contain breakpoints and other LLDB setup
  • Create application specific commands: see the GitHawk commands
  • Use named breakpoints to quickly enable and disable breakpoints
breakpoint set -n malloc -N memory
breakpoint set -n free -N memory
breakpoint disable memory

To re-enable:

breakpoint enable memory


  • Add Logs, Signposts and Points of Interest to construct a big picture of your app
  • Create custom instruments that focus on parts, whether large and small, so issues can be debugged visually
    • Instruments packages can be distributed throughout the team and packaged into a single Xcode project for easy development


  • LISP variant that describes expert systems
  • General language + functions manual - this is not specific to Instruments but presents some basic primitives that can be used with CLIPS expressions.


  • Make sure message format matches
  • Refer to Instruments documentation online. (Help > Instruments Developer Help)
  • Use the “Instrument Inspector” and its “Schemas” tab to discover provided columns

  • Can add CI step to verify Instruments traces
    • Risky since the file format is closed source
    • TraceUtility tool uses the libraries bundled in the app


  • Is there a way to avoid the absolute paths?
    • I’m still trying to figure out a good way to do this. I’ll update the docs and 360 Slack if I find one. In the meantime, you could add a symbolic link to point to a main imported file.
  • A way to not import each time:
    • target stop-hook add run code each time debugger stops. Add imports there and you can avoid having to import each time.