Struct fxprof_processed_profile::LibraryInfo
source · pub struct LibraryInfo {
pub name: String,
pub debug_name: String,
pub path: String,
pub debug_path: String,
pub debug_id: DebugId,
pub code_id: Option<String>,
pub arch: Option<String>,
pub symbol_table: Option<Arc<SymbolTable>>,
}
Expand description
A library (“binary” / “module” / “DSO”) which is loaded into a process. This can be the main executable file or a dynamic library, or any other mapping of executable memory.
Library information makes after-the-fact symbolication possible: The profile JSON contains raw code addresses, and then the symbols for these addresses get resolved later.
Fields§
§name: String
The name of this library that should be displayed in the profiler. Usually this is the filename of the binary, but it could also be any other name, such as “[kernel.kallsyms]” or “[vdso]” or “JIT”.
debug_name: String
The debug name of this library which should be used when looking up symbols. On Windows this is the filename of the PDB file, on other platforms it’s usually the same as the filename of the binary.
path: String
The absolute path to the binary file.
debug_path: String
The absolute path to the debug file. On Linux and macOS this is the same as the path to the binary file. On Windows this is the path to the PDB file.
debug_id: DebugId
The debug ID of the library. This lets symbolication confirm that it’s getting symbols for the right file, and it can sometimes allow obtaining a symbol file from a symbol server.
code_id: Option<String>
The code ID of the library. This lets symbolication confirm that it’s getting symbols for the right file, and it can sometimes allow obtaining a symbol file from a symbol server.
arch: Option<String>
An optional string with the CPU arch of this library, for example “x86_64”, “arm64”, or “arm64e”. This is used for macOS system libraries in the dyld shared cache, in order to avoid loading the wrong cache files, as a performance optimization. In the past, this was also used to find the correct sub-binary in a mach-O fat binary. But we now use the debug_id for that purpose.
symbol_table: Option<Arc<SymbolTable>>
An optional symbol table, for “pre-symbolicating” stack frames.
Usually, symbolication is something that should happen asynchronously, because it can be very slow, so the regular way to use the profiler is to store only frame addresses and no symbols in the profile JSON, and perform symbolication only once the profile is loaded in the Firefox Profiler UI.
However, sometimes symbols are only available during recording and are not
easily accessible afterwards. One such example the symbol table of the
Linux kernel: Users with root privileges can access the symbol table of the
currently-running kernel via /proc/kallsyms
, but we don’t want to have
to run the local symbol server with root privileges. So it’s easier to
resolve kernel symbols when generating the profile JSON.
This way of symbolicating does not support file names, line numbers, or inline frames. It is intended for relatively “small” symbol tables for which an address lookup is fast.
Trait Implementations§
source§impl Clone for LibraryInfo
impl Clone for LibraryInfo
source§fn clone(&self) -> LibraryInfo
fn clone(&self) -> LibraryInfo
1.0.0 · source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moresource§impl Debug for LibraryInfo
impl Debug for LibraryInfo
source§impl Hash for LibraryInfo
impl Hash for LibraryInfo
source§impl PartialEq<LibraryInfo> for LibraryInfo
impl PartialEq<LibraryInfo> for LibraryInfo
source§fn eq(&self, other: &LibraryInfo) -> bool
fn eq(&self, other: &LibraryInfo) -> bool
self
and other
values to be equal, and is used
by ==
.