Struct linux_perf_data::PerfFileReader

pub struct PerfFileReader<R: Read> { /* private fields */ }

Implementations

impl<C: Read + Seek> PerfFileReader<C>

pub fn parse_file(cursor: C) -> Result<Self, Error>

impl<R: Read> PerfFileReader<R>

pub fn endian(&self) -> Endianness

pub fn attributes(&self) -> &PerfEventAttr

The attributes which were requested for the perf event.

pub fn feature_flags(&self) -> FlagFeatureSet

The set of feature flags used in this perf file.

pub fn feature_section(&self, feature: FlagFeature) -> Option<&[u8]>

The raw data of a feature section.

pub fn build_ids(&self) -> Result<HashMap<DsoKey, DsoBuildId>, Error>

Returns a map of build ID entries. perf record creates these records for any DSOs which it thinks have been “hit” in the profile. They supplement Mmap events the perf event stream; those usually don’t come with build IDs.

This method returns a HashMap so that you can easily look up the right build ID from the DsoKey in an Mmap event. For some DSOs, the path in the raw Mmap event can be different from the path in the build ID record; for example, the Mmap event for the kernel (“vmlinux”) image could have the path “[kernel.kallsyms]_text”, whereas the corresponding build ID record might have the path “[kernel.kallsyms]” (without the trailing “_text”), or it could even have the full absolute path to a vmlinux file. The DsoKey canonicalizes those differences away.

Having the build ID for a DSO allows you to do the following:

• If the DSO file has changed in the time since the perf.data file was captured, you can detect this change because the new file will have a different build ID.
• If debug symbols are installed for the DSO, you can sometimes find the debug symbol file using the build ID. For example, you might find it at /usr/lib/debug/.build-id/b8/037b6260865346802321dd2256b8ad1d857e63.debug
• If the original DSO file is gone, or you’re trying to read the perf.data file on an entirely different machine, you can sometimes retrieve the original DSO file just from its build ID, for example from a debuginfod server.
• This also works for DSOs which are not present on the file system at all; specifically, the vDSO file is a bit of a pain to obtain. With the build ID you can instead obtain it from, say, https://debuginfod.elfutils.org/buildid/0d82ee4bd7f9609c367095ba0bedf155b71cb058/executable

This method is a bit lossy. We discard the pid, because it seems to be always -1 in the files I’ve tested. We also discard any entries for which we fail to create a DsoKey.

pub fn sample_time_range(&self) -> Result<Option<SampleTimeRange>, Error>

The timestamp of the first and the last sample in this file.

pub fn hostname(&self) -> Result<Option<&str>, Error>

The hostname where the data was collected (uname -n).

pub fn os_release(&self) -> Result<Option<&str>, Error>

The OS release where the data was collected (uname -r).

pub fn perf_version(&self) -> Result<Option<&str>, Error>

The perf user tool version where the data was collected. This is the same as the version of the Linux source tree the perf tool was built from.

pub fn arch(&self) -> Result<Option<&str>, Error>

The CPU architecture (uname -m).

pub fn nr_cpus(&self) -> Result<Option<NrCpus>, Error>

A structure defining the number of CPUs.

pub fn cpu_desc(&self) -> Result<Option<&str>, Error>

The description of the CPU. On x86 this is the model name from /proc/cpuinfo.

pub fn cpu_id(&self) -> Result<Option<&str>, Error>

The exact CPU type. On x86 this is vendor,family,model,stepping. For example: GenuineIntel,6,69,1

pub fn is_stats(&self) -> bool

If true, the data section contains data recorded from perf stat record.

pub fn next_record(&mut self) -> Result<Option<ParsedRecord<'_>>, Error>

Emits records in the correct order (sorted by time).

It buffers records until it sees a FINISHED_ROUND record; then it sorts the buffered records and emits them one by one.