16 releases
0.2.0-rc.2 | Nov 5, 2024 |
---|---|
0.2.0-rc.0 | Jun 10, 2024 |
0.2.0-alpha.11 | Feb 23, 2024 |
0.2.0-alpha.9 | Dec 11, 2023 |
0.1.0 |
|
#37 in Debugging
33,997 downloads per month
Used in 7 crates
(5 directly)
700KB
15K
SLoC
blazesym
blazesym is a library that can be used to symbolize addresses. Address symbolization is a common problem in tracing contexts, for example, where users want to reason about functions by name, but low level components report only the "raw" addresses (e.g., in the form of stacktraces).
In addition to symbolization, blazesym also provides APIs for the reverse operation: looking up addresses from symbol names. That can be useful, for example, for configuring breakpoints or tracepoints.
The library aims to provide a "batteries-included" experience. That is to say, it tries to do the expected thing by default. When offering such convenience comes at the cost of performance, we aim to provide advanced APIs that allow for runtime configuration of the corresponding features.
blazesym supports a variety of formats, such as DWARF, ELF, Breakpad, and Gsym (see below for an up-to-date list).
The library is written in Rust and provides a first class C API. This crate
adheres to Cargo's semantic versioning rules. At a minimum, it
builds with the most recent Rust stable release minus five minor versions ("N -
5"). E.g., assuming the most recent Rust stable is 1.68
, the crate is
guaranteed to build with 1.63
and higher.
Status
blazesym is at the core of Meta's internal continuous profiling solution, where it handles billions of symbolization requests per day.
The library is being actively worked on, with a major goal being stabilization of the API surface. Feel free to contribute with discussions, feature suggestions, or code contributions!
As alluded to above, the library provides support for a variety of formats. For symbolization specifically, the following table lays out what features each format supports and whether blazesym can currently use this feature:
Format | Feature | Supported by format? | Supported by blazesym? |
---|---|---|---|
Breakpad | symbol size | ✔️ | ✔️ |
source code location information | ✔️ | ✔️ | |
inlined function information | ✔️ | ✔️ | |
ELF | symbol size | ✔️ | ✔️ |
source code location information | ✖️ | ✖️ | |
inlined function information | ✖️ | ✖️ | |
DWARF | symbol size | ✔️ | ✔️ |
source code location information | ✔️ | ✔️ | |
inlined function information | ✔️ | ✔️ | |
Gsym | symbol size | ✔️ | ✔️ |
source code location information | ✔️ | ✔️ | |
inlined function information | ✔️ | ✔️ | |
Ksym | symbol size | ✖️ | ✖️ |
source code location information | ✖️ | ✖️ | |
inlined function information | ✖️ | ✖️ |
Here is rough roadmap of currently planned features (in no particular order):
- Fully support handling of kernel addresses
- Support BPF program symbolization (https://github.com/libbpf/blazesym/issues/826)
- Support symbolization of kernel module addresses
- Support remote symbolization use cases for kernel addresses
- Switch to using
gimli
for DWARF parsing- doing so will allow us to:
- Support more versions of the DWARF standard (https://github.com/libbpf/blazesym/issues/42 & https://github.com/libbpf/blazesym/issues/57)
- Support split debug information (https://github.com/libbpf/blazesym/issues/60)
- Support inlined function lookup for DWARF (https://github.com/libbpf/blazesym/issues/192)
- doing so will allow us to:
- Support symbolization of addresses in APKs (relevant for Android) (https://github.com/libbpf/blazesym/pull/222 & https://github.com/libbpf/blazesym/pull/227)
- Support ELF32 binaries (https://github.com/libbpf/blazesym/issues/53)
- Support handling of compressed debug information (https://github.com/libbpf/blazesym/issues/581)
- Support demangling of Rust & C++ symbol names (https://github.com/libbpf/blazesym/issues/50)
- Support remote symbolization (https://github.com/libbpf/blazesym/issues/61)
- Add APIs for address normalization (https://github.com/libbpf/blazesym/pull/114, https://github.com/libbpf/blazesym/pull/128, ...)
- Support advanced symbolization use cases involving
debuginfod
(https://github.com/libbpf/blazesym/issues/203)
OS Support
The library's primary target operating system is Linux (it should work on all semi-recent kernel versions and distributions).
MacOS and Windows are supported for file based symbolization (i.e., using one of
the Breakpad
, Elf
, or Gsym
symbolization sources). Standalone address
normalization as well as process or kernel symbolization are not supported.
Build & Use
blazesym requires a standard Rust toolchain and can be built using the Cargo
project manager (e.g., cargo build
).
Rust
Consumption from a Rust project should happen via Cargo.toml
:
[dependencies]
blazesym = "=0.2.0-rc.2"
For a quick set of examples please refer to the examples/
folder.
Please refer to the documentation for a
comprehensive explanation of individual types and functions.
C
The companion crate blazesym-c
provides the means for interfacing
with the library from C. Please refer to its README
for
usage details.
Command-line
The library also comes with a command line interface for quick experimentation and debugging. You can run it directly from the repository, e.g.:
cargo run -p blazecli -- symbolize elf --path /lib64/libc.so.6 00000000000caee1
Please refer to its README
as well as the help text
for additional information and usage instructions.
Statically linked binaries for various target triples are available on-demand here.
Dependencies
~0.1–1.5MB
~29K SLoC