1// The file format generated by report_sample.proto is as below: 2// LittleEndian32(record_size_0) 3// message Record(record_0) (having record_size_0 bytes) 4// LittleEndian32(record_size_1) 5// message Record(record_1) (having record_size_1 bytes) 6// ... 7// LittleEndian32(record_size_N) 8// message Record(record_N) (having record_size_N bytes) 9// LittleEndian32(0) 10 11syntax = "proto2"; 12option optimize_for = LITE_RUNTIME; 13package simpleperf_report_proto; 14option java_package = "com.android.tools.profiler.proto"; 15option java_outer_classname = "SimpleperfReport"; 16 17message Sample { 18 // Wall clock time for current sample. 19 // By default, it is perf clock used in kernel. 20 optional uint64 time = 1; 21 optional int32 thread_id = 2; 22 23 message CallChainEntry { 24 // virtual address of the instruction in elf file 25 optional uint64 vaddr_in_file = 1; 26 27 // index of the elf file containing the instruction 28 optional uint32 file_id = 2; 29 30 // symbol_id refers to the name of the function containing the instruction. 31 // If the function name is found, it is a valid index in the symbol table 32 // of File with 'id' field being file_id, otherwise it is -1. 33 optional int32 symbol_id = 3; 34 } 35 36 repeated CallChainEntry callchain = 3; 37 38 // Simpleperf generates one sample whenever a specified amount of events happen 39 // while running a monitored thread. So each sample belongs to one event type. 40 // Event type can be cpu-cycles, cpu-clock, sched:sched_switch or other types. 41 // By using '-e' option, we can ask simpleperf to record samples for one or more 42 // event types. 43 // Each event type generates samples independently. But recording more event types 44 // will cost more cpu time generating samples, which may affect the monitored threads 45 // and sample lost rate. 46 // event_count field shows the count of the events (belong to the sample's event type) 47 // that have happened since last sample (belong to the sample's event type) for the 48 // same thread. However, if there are lost samples between current sample and previous 49 // sample, the event_count is the count of events from the last lost sample. 50 optional uint64 event_count = 4; 51 52 // An index in meta_info.event_type, shows which event type current sample belongs to. 53 optional uint32 event_type_id = 5; 54} 55 56message LostSituation { 57 optional uint64 sample_count = 1; 58 optional uint64 lost_count = 2; 59} 60 61message File { 62 // unique id for each file, starting from 0, and add 1 each time. 63 optional uint32 id = 1; 64 65 // file path, like /system/lib/libc.so. 66 optional string path = 2; 67 68 // symbol table of the file. 69 repeated string symbol = 3; 70} 71 72message Thread { 73 optional uint32 thread_id = 1; 74 optional uint32 process_id = 2; 75 optional string thread_name = 3; 76} 77 78message MetaInfo { 79 repeated string event_type = 1; 80} 81 82message Record { 83 oneof record_data { 84 Sample sample = 1; 85 LostSituation lost = 2; 86 File file = 3; 87 Thread thread = 4; 88 MetaInfo meta_info = 5; 89 } 90}