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>

proto: Fix warnings for protoc v3

protoc v3 introduces a new syntax for proto files and warns when the
syntax is not explicitly stated.

protoc relies on the fact that undefined preprocessor symbols are
explanded to 0 but since we use -Wundef they end up generating
warnings.

Change-Id: If07abeb54e932469c8f2c4d38634a97fdae40f77
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>

proto, probe: Add elastic trace probe to o3 cpu

The elastic trace is a type of probe listener and listens to probe points
in multiple stages of the O3CPU. The notify method is called on a probe
point typically when an instruction successfully progresses through that
stage.

As different listener methods mapped to the different probe points execute,
relevant information about the instruction, e.g. timestamps and register
accesses, are captured and stored in temporary InstExecInfo class objects.
When the instruction progresses through the commit stage, the timing and the
dependency information about the instruction is finalised and encapsulated in
a struct called TraceInfo. TraceInfo objects are collected in a list instead
of writing them out to the trace file one a time. This is required as the
trace is processed in chunks to evaluate order dependencies and computational
delay in case an instruction does not have any register dependencies. By this
we achieve a simpler algorithm during replay because every record in the
trace can be hooked onto a record in its past. The instruction dependency
trace is written out as a protobuf format file. A second trace containing
fetch requests at absolute timestamps is written to a separate protobuf
format file.

If the instruction is not executed then it is not added to the trace.
The code checks if the instruction had a fault, if it predicated
false and thus previous register values were restored or if it was a
load/store that did not have a request (e.g. when the size of the
request is zero). In all these cases the instruction is set as
executed by the Execute stage and is picked up by the commit probe
listener. But a request is not issued and registers are not written.
So practically, skipping these should not hurt the dependency modelling.

If squashing results in squashing younger instructions, it may happen that
the squash probe discards the inst and removes it from the temporary
store but execute stage deals with the instruction in the next cycle which
results in the execute probe seeing this inst as 'new' inst. A sequence
number of the last processed trace record is used to trap these cases and
not add to the temporary store.

The elastic instruction trace and fetch request trace can be read in and
played back by the TraceCPU.

mem: change the namespace Message to ProtoMessage
The namespace Message conflicts with the Message data type used extensively
in Ruby. Since Ruby is being moved to the same Master/Slave ports based
configuration style as the rest of gem5, this conflict needs to be resolved.
Hence, the namespace is being renamed to ProtoMessage.

mem: Edit proto Packet and enhance the python script

This patch changes the decode script to output the optional fields of
the proto message Packet, namely id and flags. The flags field is set
by the communication monitor.

The id field is useful for CPU trace experiments, e.g. linking the
fetch side to decode side. It had to be renamed because it clashes
with a built in python function id() for getting the "identity" of an
object.

This patch also takes a few common function definitions out from the
multiple scripts and adds them to a protolib python module.

mem: Add a generic id field to the packet trace

This patch adds an optional generic 64-bit identifier field to the
packet trace. This can be used to store the sequential number of the
instruction that gave rise to the packet, thread id, master id,
"sub"-master within a larger module etc. As the field is optional it
has a marginal cost if not used.

mem: Add optional request flags to the packet trace

This patch adds an optional flags field to the packet trace to encode
the request flags that contain information about whether the request
is (un)cacheable, instruction fetch, preftech etc.

mem: Add tracing support in the communication monitor

This patch adds packet tracing to the communication monitor using a
protobuf as the mechanism for creating the trace.

If no file is specified, then the tracing is disabled. If a file is
specified, then for every packet that is successfully sent, a protobuf
message is serialized to the file.