pub struct SymbolManager<H: FileAndPathHelper> { /* private fields */ }Implementations§
Source§impl<H, F, FL> SymbolManager<H>
impl<H, F, FL> SymbolManager<H>
pub fn with_helper(helper: H) -> Self
pub async fn load_source_file( &self, debug_file_location: &H::FL, source_file_path: &SourceFilePath, ) -> Result<String, Error>
Sourcepub async fn load_symbol_map(
&self,
library_info: &LibraryInfo,
) -> Result<SymbolMap<H>, Error>
pub async fn load_symbol_map( &self, library_info: &LibraryInfo, ) -> Result<SymbolMap<H>, Error>
Obtain a symbol map for the library, given the (partial) LibraryInfo.
At least the debug_id has to be given.
Sourcepub async fn load_external_file(
&self,
debug_file_location: &H::FL,
external_file_path: &str,
) -> Result<ExternalFileSymbolMap<H::F>, Error>
pub async fn load_external_file( &self, debug_file_location: &H::FL, external_file_path: &str, ) -> Result<ExternalFileSymbolMap<H::F>, Error>
Load and return an external file which may contain additional debug info.
This is used on macOS: When linking multiple .o files together into a library or
an executable, the linker does not copy the dwarf sections into the linked output.
Instead, it stores the paths to those original .o files, using OSO stabs entries.
A SymbolMap for such a linked file will not find debug info, and will return
FramesLookupResult::External from the lookups. Then the address needs to be
looked up in the external file.
Also see SymbolMap::lookup_external.
Sourcepub async fn load_binary(
&self,
info: &LibraryInfo,
) -> Result<BinaryImage<F>, Error>
pub async fn load_binary( &self, info: &LibraryInfo, ) -> Result<BinaryImage<F>, Error>
Returns the binary for the given (partial) LibraryInfo.
This consults the helper to get candidate paths to the binary.