Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously Serializable::serializeAll called SimObject::
serializeAll. This created an unnecessary dependency. This
change makes Serializable responsible for the generation
of the checkpoint file, and then the SimObjects will
perform the serialization of the object using that file.
With this change serialize.hh contains only functions
related to the (un)serialization of basic types or
objects that inherit from Serializable. As a general
rule, functions related to the (un)serialization of
specific/other types must be defined in the file that
introduces that type.
Change-Id: I9438b799d7e9d4c992a62c7f9d1f15f3f3250a5a
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38740
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
SimObjects keep a static list with all existing
SimObjects. This list is then used to serialize
all objects declared in the system. If these
macros were used then an object would be serialized
more than once, which is not a correct behavior.
Change-Id: Idc4433ec2a23a21ee5ee2b7cc2facfe3dd979859
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46720
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
With this change serialize.hh is no longer responsible
for the (un)serialization of events. As a general rule,
rules to (un)serialize non-basic types should be defined
at the file that introduces that type. Therefore,
(UN)SERIALIZE_EVENT have been moved to eventq.hh.
Globals has a single instance which must be serialized
and unserialized. Instead of having a stray global
variable handled by Serialization, we pass its management
to Root. As a side effect, Globals is assigned its own
files: sim/globals.(cc/hh).
Finally, 'unserializeGlobals()' is removed, so that
Root can fully handle Globals' serialization. This
breaks checkpoint compatibility, so a checkpoint
upgrader is added.
Change-Id: I9c8e57306f83f9cc30ab2b745a4972755191bec4
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43586
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, and 2 levels of indentation, using:
grep -nrE --exclude-dir=systemc \
"^ *class [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>class X ... {
by:
<indent level>class X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc
"^class [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^class ([A-Za-z].*) \{$/class \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ class [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ class ([A-Za-z].*) \{$/ class \1\n \{/g'
and so on.
Change-Id: I17615ce16a333d69867b27c7bae0f4fdafd8b2eb
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39015
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The warning happens when a key is present in the checkpoint but not in the
values that gem5 source code knows about.
To do this, we must expose iteration over IniFile section keys. To not
have to make those classes public, a visitor method is implemented.
Change-Id: I23340a953f3e604642b97690a7328b10fdd740a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37575
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
In clang, the following error was given:
```
In file included from build/X86/sim/eventq.hh:51:
build/X86/sim/serialize.hh:533:19: error: 'ScopedCheckpointSection' is a protected member of 'Serializable'
Serializable::ScopedCheckpointSection sec(os, sectionName);
^
build/X86/sim/serialize.hh:175:11: note: declared protected here
class ScopedCheckpointSection {
^
```
The use, at line 533, was introduced in this commit:
https://gem5-review.googlesource.com/c/public/gem5/+/36135
This can be fixed by making ScopedCheckpointSection public.
Change-Id: Ib6ffba18d5e8c37980d4febb548f2405cb45ce8c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37915
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The parseParam and showParam functions partially worked using template
specialization, and partially worked using function overloading. The
template specialization could be resolved later once other functions
were added, but the regular function overloads could not. That meant
that it was practically impossible to add new definitions of those two
functions local to the types they worked with.
Also, because C++ does not allow partial specialization of template
functions, it would not be possible to truly use specialization to wire
in BitUnion types.
To fix these problems, these functions have been turned into structs
which wrap static functions. These can be partially specialized as
desired, making them compatible with BitUnions. Also, it's not possible
to overload structures like it is with functions, so only specialization
is considered, not overloading.
While making these changes, these functions (now structs) were also
reworked so that they share implementation more, and are generally
more streamlined.
Given the fact that the previous parseParam and showParam functions
could not actually be expanded beyond serialize.hh, and were not
actually called directly by any code outside of that file, they should
have never been considered part of the API.
Now that these structs actually *can* be specialized outside of this
file, they should be considered part of the interface.
Change-Id: Ic8e677b97fda8378ee1da1f3cf6001e02783fde3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36280
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These had been written specifically for the vector, list, set, and C
style array types. This change reworks them to share an implementation,
and to work with more general types. The arrayParamOut method requires
std::begin() and std::end() to accept that type, and the arrayParamIn
method requires either insert or push_back, or the type to be an array.
Also fix up a couple of files which accidentally depended on includes in
the serialize headers which are no longer necessary.
Change-Id: I6ec4fe3bb900603bbb4e35c4efa620c249942452
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36277
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The bitunion is not being initialized on constructor to avoid
performance overhead, and that generated a maybe-unitialized
error when a sub-class was being copied before assigned in
serialize's parseParam() in some compilers.
This patch adds zero-initialization to the problematic variable
to appease the compiler.
Change-Id: I90fa6aa356b3e14ec25e3294b17ed10f429a9a38
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/15635
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This patch is moving template overloading for BitUnions into the
showParam, parseParams functions. Henceforth BitUnion types will use the
common param wrapper.
This patch implicitly implements (UN)SERIALIZE_CONTAINER for BitUnions.
Change-Id: I0e1faadb4afd4dc9de5dc5fca40041e349c9ba73
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13636
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This patch is moving the definitions of paramIn/Out templates to
the header file. In this way we gain:
1) We don't have to do explicit instantiation anymore for user defined
types. This spares us from including data type header files into
serialize.cc
2) We can overload show/parseParam for BitUnions or any other type
that requires special handling when serializing. Just by overloading
the two templates we get all the containers' (list, vector, array..)
serialization for free
2) gtest: With the idea of adding unit tests for Serializable objects,
we can avoid importing serialize.cc and just redefine Serializable
methods in the test source, implementing a Serializable stub
Change-Id: I45a9bb87d5ef886a3668fd477005cd105f612e36
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13635
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
They are now oriented around a class which makes it easy to provide
custom setter/getter functions which let you set or read bits in an
arbitrary way.
Future additions may add the ability to add custom bitfield methods,
and index-able bitfields.
Change-Id: Ibd6d4d9e49107490f6dad30a4379a8c93bda9333
Reviewed-on: https://gem5-review.googlesource.com/7201
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Used cppclean to help identify useless includes and removed them. This
involved erroneously included headers, but also cases where forward
declarations could have been used rather than a full include.
When loading a checkpoint, it's sometimes desirable to be able to test
whether an entry within a secion exists. This is currently done
automatically in the UNSERIALIZE_OPT_SCALAR macro, but it isn't
possible to do for arrays, containers, or enums. Instead of adding
even more macros, add a helper function (CheckpointIn::entryExists())
that tests for the presence of an entry.
Change-Id: I4b4646b03276b889fd3916efefff3bd552317dbc
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
The last SimObject using the legacy serialize API with non-const
methods has now been transitioned to the new API. This changeset
removes the serializeOld() methods from the serialization base class
as they are no longer used.
This commit addresses gem5 checkpoints' linear versioning bottleneck.
Since development is distributed across many private trees, there exists
a sort of 'race' for checkpoint version numbers: internally a checkpoint
version may be used but then resynchronizing with the external tree causes
a conflict on that version. This change replaces the linear version number
with a set of unique strings called tags. Now the only conflicts that can
arise are of tag names, where collisions are much easier to avoid.
The checkpoint upgrader (util/cpt_upgrader.py) upgrades the version
representation, as one would expect. Each tag version implements its
upgrader code in a python file in the util/cpt_upgraders directory
rather than adding a function to the upgrader script itself.
The version tags are stored in the 'Globals' section rather than 'root'
(as the version was previously) because 'Globals' gets unserialized
first and can provide a warning before any other unserialization errors
can occur.
This is in support of tag-based checkpoint versioning. It should be
possible to examine an optional parameter in a checkpoint during
unserialization and not have it throw a warning.
Event auto-serialization no longer in use and has been broken ever
since the introduction of PDES support almost two years
ago. Additionally, serializing the individual event queues is
undesirable since it exposes the thread structure of the
simulator. What this means in practice is that the number of threads
in the simulator must be the same when taking a checkpoint and when
loading the checkpoint.
This changeset removes support for the AutoSerialize event flag and
the associated serialization code.
The object resolver isn't serialization specific and shouldn't live in
serialize.hh. Move it to sim_object.hh since it queries to the
SimObject hierarchy.
This patch extends the previous patch's alterations around fd_map. It cleans
up some of the uglier code in the process file and replaces it with a more
concise C++11 version. As part of the changes, the FdMap class is pulled out
of the Process class and receives its own file.
Events expected to be unserialized using an event-specific
unserializeEvent call. This call was never actually used, which meant
the events relying on it never got unserialized (or scheduled after
unserialization).
Instead of relying on a custom call, we now use the normal
serialization code again. In order to schedule the event correctly,
the parrent object is expected to use the
EventQueue::checkpointReschedule() call. This happens automatically
for events that are serialized using the AutoSerialize mechanism.
Objects that are can be serialized are supposed to inherit from the
Serializable class. This class is meant to provide a unified API for
such objects. However, so far it has mainly been used by SimObjects
due to some fundamental design limitations. This changeset redesigns
to the serialization interface to make it more generic and hide the
underlying checkpoint storage. Specifically:
* Add a set of APIs to serialize into a subsection of the current
object. Previously, objects that needed this functionality would
use ad-hoc solutions using nameOut() and section name
generation. In the new world, an object that implements the
interface has the methods serializeSection() and
unserializeSection() that serialize into a named /subsection/ of
the current object. Calling serialize() serializes an object into
the current section.
* Move the name() method from Serializable to SimObject as it is no
longer needed for serialization. The fully qualified section name
is generated by the main serialization code on the fly as objects
serialize sub-objects.
* Add a scoped ScopedCheckpointSection helper class. Some objects
need to serialize data structures, that are not deriving from
Serializable, into subsections. Previously, this was done using
nameOut() and manual section name generation. To simplify this,
this changeset introduces a ScopedCheckpointSection() helper
class. When this class is instantiated, it adds a new /subsection/
and subsequent serialization calls during the lifetime of this
helper class happen inside this section (or a subsection in case
of nested sections).
* The serialize() call is now const which prevents accidental state
manipulation during serialization. Objects that rely on modifying
state can use the serializeOld() call instead. The default
implementation simply calls serialize(). Note: The old-style calls
need to be explicitly called using the
serializeOld()/serializeSectionOld() style APIs. These are used by
default when serializing SimObjects.
* Both the input and output checkpoints now use their own named
types. This hides underlying checkpoint implementation from
objects that need checkpointing and makes it easier to change the
underlying checkpoint storage code.
BitUnion instances can normally not be used with the SERIALIZE_SCALAR
and UNSERIALIZE_SCALAR macros due to the way they are converted
between their storage type and their actual type. This changeset adds
a set of parm(In|Out) functions specifically for gem5 bit unions to
work around the issue.
Add the ability to build libgem5 without embedded Python or the
ability to configure with Python.
This is a prelude to a patch to allow config.ini files to be loaded
into libgem5 using only C++ which would make embedding gem5 within
other simulation systems easier.
This adds a few registration interfaces to things which cross
between Python and C++. Namely: stats dumping and SimObject resolving
Analogous to ee049bf (for x86). Requires a bump of the checkpoint version
and corresponding upgrader code to move the condition code register values
to the new register file.
This patch adds a fix for older checkpoints before support for
multiple event queues were added in changeset 2cce74fe359e. The change
in checkpoint version should really hav ebeen part of the
aforementioned changeset.
Upon aggregating records, serialize system's cache-block size, as the
cache-block size can be different when restoring from a checkpoint. This way,
we can correctly read all records when restoring from a checkpoints, even if
the cache-block size is different.
Note, that it is only possible to restore from a checkpoint if the
desired cache-block size is smaller or equal to the cache-block size
when the checkpoint was taken; we can split one larger request into
multiple small ones, but it is not reliable to do the opposite.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
Note: AArch64 and AArch32 interworking is not supported. If you use an AArch64
kernel you are restricted to AArch64 user-mode binaries. This will be addressed
in a later patch.
Note: Virtualization is only supported in AArch32 mode. This will also be fixed
in a later patch.
Contributors:
Giacomo Gabrielli (TrustZone, LPAE, system-level AArch64, AArch64 NEON, validation)
Thomas Grocutt (AArch32 Virtualization, AArch64 FP, validation)
Mbou Eyole (AArch64 NEON, validation)
Ali Saidi (AArch64 Linux support, code integration, validation)
Edmund Grimley-Evans (AArch64 FP)
William Wang (AArch64 Linux support)
Rene De Jong (AArch64 Linux support, performance opt.)
Matt Horsnell (AArch64 MP, validation)
Matt Evans (device models, code integration, validation)
Chris Adeniyi-Jones (AArch64 syscall-emulation)
Prakash Ramrakhyani (validation)
Dam Sunwoo (validation)
Chander Sudanthi (validation)
Stephan Diestelhorst (validation)
Andreas Hansson (code integration, performance opt.)
Eric Van Hensbergen (performance opt.)
Gabe Black
