simpleperf/report_sample.proto

// The file format generated by report_sample.proto is as below:
// char magic[10] = "SIMPLEPERF";
// LittleEndian16(version) = 1;
// LittleEndian32(record_size_0)
// message Record(record_0) (having record_size_0 bytes)
// LittleEndian32(record_size_1)
// message Record(record_1) (having record_size_1 bytes)
// ...
// LittleEndian32(record_size_N)
// message Record(record_N) (having record_size_N bytes)
// LittleEndian32(0)

syntax = "proto2";
option optimize_for = LITE_RUNTIME;
package simpleperf_report_proto;
option java_package = "com.android.tools.profiler.proto";
option java_outer_classname = "SimpleperfReport";

message Sample {
  // Wall clock time for current sample.
  // By default, it is perf clock used in kernel.
  optional uint64 time = 1;
  optional int32 thread_id = 2;

  message CallChainEntry {
    // virtual address of the instruction in elf file
    optional uint64 vaddr_in_file = 1;

    // index of the elf file containing the instruction
    optional uint32 file_id = 2;

    // symbol_id refers to the name of the function containing the instruction.
    // If the function name is found, it is a valid index in the symbol table
    // of File with 'id' field being file_id, otherwise it is -1.
    optional int32 symbol_id = 3;
  }

  repeated CallChainEntry callchain = 3;

  // Simpleperf generates one sample whenever a specified amount of events happen
  // while running a monitored thread. So each sample belongs to one event type.
  // Event type can be cpu-cycles, cpu-clock, sched:sched_switch or other types.
  // By using '-e' option, we can ask simpleperf to record samples for one or more
  // event types.
  // Each event type generates samples independently. But recording more event types
  // will cost more cpu time generating samples, which may affect the monitored threads
  // and sample lost rate.
  // event_count field shows the count of the events (belong to the sample's event type)
  // that have happened since last sample (belong to the sample's event type) for the
  // same thread. However, if there are lost samples between current sample and previous
  // sample, the event_count is the count of events from the last lost sample.
  optional uint64 event_count = 4;

  // An index in meta_info.event_type, shows which event type current sample belongs to.
  optional uint32 event_type_id = 5;
}

message LostSituation {
  optional uint64 sample_count = 1;
  optional uint64 lost_count = 2;
}

message File {
  // unique id for each file, starting from 0, and add 1 each time.
  optional uint32 id = 1;

  // file path, like /system/lib/libc.so.
  optional string path = 2;

  // symbol table of the file.
  repeated string symbol = 3;

  // mangled symbol table of the file.
  repeated string mangled_symbol = 4;
}

message Thread {
  optional uint32 thread_id = 1;
  optional uint32 process_id = 2;
  optional string thread_name = 3;
}

message MetaInfo {
  repeated string event_type = 1;
  optional string app_package_name = 2;
}

message Record {
  oneof record_data {
    Sample sample = 1;
    LostSituation lost = 2;
    File file = 3;
    Thread thread = 4;
    MetaInfo meta_info = 5;
  }
}