# bazel_cache_reader

`bazel_cache_reader` is used for helping `lldb` find DSYMs for builds done with
Tulsi. DSYM locations are stored by Tulsi in a sqlite3 database located at
`~/Library/Application Support/Tulsi/Scripts/symbol_cache.db`.
`lldb` is set up to find the DSYMs using `~/.lldbinit` as specified
[here](https://lldb.llvm.org/use/symbols.html).

Easy debugging of `bazel_cache_reader` can be done using `Console.app`, turning
on "debug and info" messages, and filtering for `bazel_cache_reader`.

# bazel_cache_reader

`bazel_cache_reader` is used for helping `lldb` find dSYMs for builds done with
Tulsi. dSYM locations are stored by Tulsi in a sqlite3 database located at
`~/Library/Application Support/Tulsi/Scripts/symbol_cache.db`.
`lldb` is set up to find the dSYMs using `~/.lldbinit` as specified
[here](https://lldb.llvm.org/use/symbols.html).

Easy debugging of `bazel_cache_reader` can be done using `Console.app`, turning
on "debug and info" messages, and filtering for `bazel_cache_reader`.

Historically, this tool exists to act as a fallback when Spotlight cannot find
the dSYM bundle generated by a build. This tool has been written in C to avoid
overhead witnessed when referencing a script via `DBGShellCommands`. For even a
small iOS build, `lldb` will perform hundreds of debug symbol lookups through
the scripts referenced by `DBGShellCommands` and Spotlight when it starts a
debug session. `lldb` tries to match debug symbols for every target to debug,
including custom dynamic frameworks and system frameworks. This latency can
cause the debug session to time out before it is able to start, as witnessed
during initial prototyping as a Python script.

Add historical context behind the bazel_cache_reader tool.
Add historical context behind the bazel_cache_reader tool.

PiperOrigin-RevId: 325861740
