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
- Add breakpoint sounds to quickly identify issues
- Import LLDB commands/breakpoints from a file (put this in
command source ~/.lldb-scripts/sounds/breakpoints.txt
- Auto-continuing sound breakpoints tagged with a name (contents of
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
aproposcommand to search commands and help text
log enable -f /tmp/log.txt lldb allenable logging to a file
value.GetError().GetCString()retrieve string from error in SBValue (using LLDB’s Python APIs)
- Use system
os_logmessages for debugging
- Create Custom Instruments for system APIs: CommonInstruments repo
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
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 addrun code each time debugger stops. Add imports there and you can avoid having to import each time.