mem: Add a "map" of packet IDs to strings in probe traces.
This map is intended to map from request MasterIDs to master names. It could
be used to map to arbitrary strings in other situations, however.
The original idea to store this information was to add a new message type
which would store one ID and the string associated with it. This change stores
the IDs in the header instead so that they'll be easy to find and all
available before the packet data.
One downside of this approach is that it won't be possible to add new master
ID strings as they come up during a trace. If that becomes an issue, the two
approaches could be combined and messages could be added which would augment
the map in the header.
Also worth mentioning is that the proto2 version of the protobuf description
language does not support the "map" field type, and the protoc compiler on my
workstation doesn't support proto3. Because that's such an appropriate
representation for this data, the map is represented in an equivalent format
described in the proto3 documentation.
Change-Id: I137c8611c33d9ce6589e196d50c8638c1d88750c
Reviewed-on: https://gem5-review.googlesource.com/4782
Reviewed-by: Rahul Thakur <rjthakur@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
diff --git a/src/proto/packet.proto b/src/proto/packet.proto
index 53f69e5..1fb7e2f 100644
--- a/src/proto/packet.proto
+++ b/src/proto/packet.proto
@@ -47,6 +47,16 @@
required string obj_id = 1;
optional uint32 ver = 2 [default = 0];
required uint64 tick_freq = 3;
+
+ // This is supposed to be wire equivalent to the "map" construct supported
+ // by the proto3 version of the protobuf description syntax. When that
+ // becomes widely available, this should be converted over to use it.
+ message IdStringEntry {
+ optional uint32 key = 1;
+ optional string value = 2;
+ }
+
+ repeated IdStringEntry id_strings = 4;
}
// Each packet in the trace contains a tick (which can be translated
