Add a unit test for sim/serialize.hh.
==Bugs==
arrayParamIn cannot parse strings with spaces. Since spaces
are used as delimiters, strings containing spaces are parsed
as multiple entries of the array. The test that checks for
this has been disabled.
==Unexpected Behavior==
Serialization has an unexpected behavior when returning to
previous scopes. For example,
...
SCS scs(cpt, "S1")
paramOut(cpt, "param1", integer1)
{
SCS scs_2(cpt, "S2")
paramOut(cpt, "param2", integer2)
}
paramOut(cpt, "param3", integer3)
will generate the output:
...
[S1]
param1=1
[S2]
param2=2
param3=3
But the user might expect:
...
[S1]
param1=1
[S2]
param2=2
[S1]
param3=3
==Incovenient Behavior==
arrayParamIn with a std::array parameter is slightly
incovenient, since the raw data pointer must be extracted.
It may be worth it to add a template specialization.
==Not Tested==
paramInImpl is not being directly tested because it should
not be used as an external API - paramIn and optParamIn
should be used instead.
arrayParamIn with an InsertIterator parameter is not being
directly tested because the other versions should be used
instead.
Change-Id: If0c8f045aa317790d5fcb32e48629b113b62efc5
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41337
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
These are HDF5, PNG, FENV, and TUNTAP support, all of which add
capabilities to gem5 which can be ignored if not wanted. It could be
argued that FENV changes behavior because it makes setting the FP
rounding mode work or not as used by SPARC, but since the difference is
trivial and in a niche area, that (along with the other options) doesn't
seem to justify having a top level control in the build system.
Since these are no longer options which say whether to *use* a
particular feature, and are instead flags which say whether we *have* a
particular feature, change their names from USE_* to HAVE_*, to stay
consistent with other variables.
Most of the remaining USE_* flags, KVM, FASTMODEL, SYSTEMC, and
(indirectly) USE_PYTHON, toggle on and off major systems which can have
a significant effect on boot time, or, in the case of FASTMODEL, even
consume external resources which may not be available and which may
break the build.
USE_POSIX_TIMER was also left alone since it selects between two
implementations of some functions. By forcing it to be on or off
depending on the host, we would be forcing some code to be excluded in
either case. That would make that other code impossible to test without
hacking up scons or modifying the host machine.
Change-Id: I0b03f23e65478caefd50cd3516974386e3dbf0db
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40964
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Use SConsopts files local to individual domains to pull
non-foundational build code out of SConstruct. This greatly simplifies
SConstruct, and also makes it easier to find build configuration having
to do with particular pieces of gem5.
This change also converts some python level variables, all_protocols,
protocol_dirs, and slicc_includes, into the environment where the timing
of their initialization is more flexible.
Change-Id: Ie61ceb75ae9e5557cc400603c972a9582e99c1ea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40872
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
This "UnitTest" was really not a unit test, it was a timing utility for
measuring the performance of gem5's cprintf implementation. The name was
misleading, but more than that, it was linked against all of gem5 which
created a approximately 1.5 gigabyte binary for what is a very small
program.
Instead, the new version of cprintftime, which has the same
functionality as the old version, weighs in at a svelte 500k with debug
information.
This also trims down the number of misleading "UnitTest" entries to 3,
getting us closer to the point where we can eliminate that type of
entity entirely.
Change-Id: Id30d094f2844e948fe67e820c89412f8667aaa52
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40617
Maintainer: Gabe Black <gabe.black@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Debug flags are flags that aid with debugging by printing
relevant information when enabled. Debug-formatting flags
define how the debug flags will print the information.
Although a viability, this patch does not support declaring
compound format flags.
As a side effect, now debug flags and debug-formatting flags
are printed in different lists, when using --debug-help.
Change-Id: Ieae68745276218cf4e9c1d37d7bf3bd1f19709ae
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39076
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This code was at least a little Alpha specific, and now that Alpha is
gone it can no longer be compiled. We could either fix it up to work
with other/all ISAs or delete it, and the consensus was to delete it. It
could potentially be revived in the future by retrieving it from version
control.
Change-Id: Ied073f2b9b166951ecba3442cd762eb19bc690b3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32954
Reviewed-by: Steve Reinhardt <stever@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If FmtTicksOff is given, ticks are disabled for all log messages.
The original motivation of this is to bring the implementation of native
traces closer to that of other traces to help refactoring done in future
patches.
One additional advantage of this is that sometimes we want to compare
traces of a given program under different conditions, so the start of the
ROI is different, and the different initial timestamp makes a diff
useless by showing differences on every line.
Change-Id: Idd6cb105d301b3b9b064996043f4ca75ddafe0af
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22006
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This makes it easier to determine which messages come from which
flags when enabling multiple flags at once.
This commit covers the bulk of the debug messages, which use the DPRINTF*
family of macros. There however macros that use DTRACE to check for
enable, those will be covered in future patches.
Change-Id: I6738b18f08ccfd1e11f2874b426c1827b42e82a2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22004
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Testing intmath.hh and intmath.cc. Here is the
list of the functions that are tested.
intmath.isPowerOf2, intmath.power, intmath.floorLog2,
intmath.ceilLog2, intmath.divCeil, intmath.roundUp,
intmath.roundDown. Other functions are not tested,
because they are not currently used and are dead code.
Change-Id: I150ac1b5cead93c6698a8c9e9cec80bd87ef181a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22081
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Mahyar Samani <msamani@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The below list of functions were dead code and are now
deleted.
intmath.prevPrime, intmath.isPrime, intmath.leastSigBit,
intmath.floorPow2, intmath.ceilPow2, intmath.isHex,
intmath.isOct, intmath.isDec, intmath.hex2Int. The source
file intmath.cc is now effectively useless and deleted.
Change-Id: I28e4350056b8d03e02fecd5c7f7f9c62bc2df7ce
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22584
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Adding these tests supercedes the unittest/strnumtest.cc
and unittest/tokentest.cc tests. They have thereby been removed.
Function "to_number" in base/str.hh previously failed to cast negative
float/double numbers. This was due to the use of
std::numeric_limits<T>::min() instead of std::numeric_limits<T>::lowest()
to determine whether a string-to-float/double conversion was
"Out of range". Tests "StrTest.ToNumberFloatNegative" and
"StrTest.ToNumberDoubleNegative" exposed this bug. It has been fixed.
Methods "split_first" and "split_last" in base/str.hh have had their
documentation updated to remove abiguity in their functionality.
Change-Id: I16e0fe40d884e22dd010db4045857eb6e7f33d4a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22084
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are cases where the memory system needs to reason about
channel-local addresses. These are currently represented using the
Addr and AddrRange classes. This is not ideal since it doesn't provide
any type safety when working with global addresses and channel-local
addresses. This is particularly problematic when porting existing
components to work in multi-channel configurations.
This changeset introduces the new ChannelAddr and ChannelAddrRange
classes. These classes encapsulate channel-local addresses in a
contiguous address space. These can, for example, be used in a memory
controller to represent a flat address space when calculating timings
or in a sectored cache.
Change-Id: I45d4061ebc8507a10d0a4577b28796dc5ec7a469
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21600
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change creates a distinction between object files which hold
executable code, and flat files which don't. The first type of files
have entry points, symbols, etc., while the others are just blobs which
can be shoved into memory. Rather than have those aspects but stub
them out, this change creates a new base class which simply doesn't
have them.
This change also restructures the ELF loader since it's main function
was quite long and doing multiple jobs.
It stops passing the architecture and operating system to the
ObjectFile constructor, since those might not be known at the very top
of the constructor. Instead, those default to Uknown*, and then are
filled in in the constructor body if appropriate. This removes a lot
of plumbing that was hard to actually use in practice.
It also introduces a mechanism to collect generic object file formats
so that they can be tried one by one by the general createObjectFile
function, rather than listing them all there one by one. It's unlikely
that new types of object files will need to be added in a modular way
without being able to modify the core loader code, but it's cleaner to
have that abstraction and modularization like is already there for
process loaders.
Finally, to make it possible to share the code which handles zipped
files for both true object files and also files which will be loaded
into memory but are just blobs, that mechanism is pulled out into a
new class called ImageFileData. It holds a collection of segments
which are set up by the object file and may refer to regions of the
original file, buffers maintained elsewhere, or even nothing to support
bss-es. shared_ptr is used to make it easier to keep track of that
information without having to do so explicitly or worry about deleting
a buffer before everyone was done using it.
Change-Id: I92890266f2ba0a703803cccad675a3ab41f2c4af
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21467
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
A memory image can be described by an object file, but an object file
is more than a memory image. Also, it makes sense to manipulate a
memory image to, for instance, change how it's loaded into memory. That
takes on larger implications (relocations, the entry point, symbols,
etc.) when talking about the whole object file, and also modifies
aspects which may not need to change. For instance if an image needs
to be loaded into memory at addresses different from what's in the
object file, but other things like symbols need to stay unmodified.
Change-Id: Ia360405ffb2c1c48e0cc201ac0a0764357996a54
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21466
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
A pointer to it was set up in the MIPS and RISCV system classes, but
nothing ever set that pointer. The class was put in base/loader, but
didn't have anything to do (as far as I can see) with loading anything
it had a loadSegments method, but was not a subclass of ObjectFile.
Change-Id: I4b711a31df20e20ffc306709227f60aa020fca15
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21464
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This changeset add support for stat dumps in the HDF5 file
format. HDF5 is a binary data format that represents data in a
file-system-like balanced tree. It has native support for
N-dimensional arrays and binary data (e.g., frame buffers).
It has the following benefits over traditional text stat files:
* Efficient storage of time series (multiple stat dumps)
* Fast lookup of stats
* Plenty of existing tooling (e.g., Python libraries and graphical
viewers)
* File format can be used to store frame buffers together with
normal stats.
Drawbacks:
* Large startup cost (single stat dump larger than text equivalent)
* Stat dumps are slower than text
Known limitations:
* Distributions and histograms aren't supported.
HDF5 stat output can be enabled using the 'h5' URL scheme when
overriding the stat file name on gem5's command line. The following
parameters are supported:
* chunking (unsigned): Number of time steps to pre-allocate
(default: 10)
* desc (bool): Output stat descriptions (default: True)
* formulas (bool): Output derived stats (default: True)
Example gem5 command line:
./build/ARM/gem5.opt \
--stats-file="h5://stats.h5?desc=False;formulas=False" \
configs/example/fs.py
Example Python stat consumer that computes IPC:
import h5py
f = h5py.File('stats.h5', 'r')
group = f['/system/cpu']
for i, c in zip(group['committedInsts'], group['numCycles']):
print i, c, i / c
Change-Id: I351c6cbff2fb7bef9012f47876ba227ed288975b
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/8121
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
This change makes the stat system aware of the hierarchical nature of
stats. The aim is to achieve the following goals:
* Make the SimObject hierarchy explicit in the stat system (i.e.,
get rid of name() + ".foo"). This makes stat naming less fragile
and makes it possible to implement hierarchical formats like
XML/HDF5/JSON in a clean way.
* Make it more convenient to split stats into a separate
struct/class that can be bound to a SimObject. This makes the
namespace cleaner and makes stat accesses a bit more obvious.
* Make it possible to build groups of stats in C++ that can be used
in subcomponents in a SimObject (similar to what we do for
checkpoint sections). This makes it easier to structure large
components.
* Enable partial stat dumps. Some of our internal users have been
asking for this since a full stat dump can be large.
* Enable better stat access from Python.
This changeset implements solves the first three points by introducing
a class (Stats::Group) that owns statistics belonging to the same
object. SimObjects inherit from Stats::Group since they typically have
statistics.
New-style statistics need to be associated with a parent group at
instantiation time. Instantiation typically sets the name and the
description, other parameters need to be set by overriding
Group::regStats() just like with legacy stats. Simple objects with
scalar stats can typically avoid implementing regStats() altogether
since the stat name and description are both specified in the
constructor.
For convenience reasons, statistics groups can be merged into other
groups. This means that a SimObject can create a stat struct that
inherits from Stats::Group and merge it into the parent group
(SimObject). This can make the code cleaner since statistics tracking
gets grouped into a single object.
Stat visitors have a new API to expose the group structure. The
Output::beginGroup(name) method is called at the beginning of a group
and the Output::endGroup() method is called when all stats, and
sub-groups, have been visited. Flat formats (e.g., the text format)
typically need to maintain a stack to track the full path to a stat.
Legacy, flat, statistics are still supported after applying this
change. These stats don't belong to any group and stat visitors will
not see a Output::beginGroup(name) call before their corresponding
Output::visit() methods are called.
Change-Id: I9025d61dfadeabcc8ecf30813ab2060def455648
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19368
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
The former implementation of CircleBuf is functional but a bit too
tailored to match a use-case. This patches introduces a new iterable
circular queue, which adds some more functionality so it can also be
used for the newer LSQ implementation, where iteration and iterators
are a very desirable feature.
Additional contributors: Gabor Dozsa.
Change-Id: I5cfb95c8abc1f5e566a114acdbf23fc52a38ce5e
Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13127
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Most tests were named *test where * was the base name of the file being
tested, but some were named differently based on, for instance, the
name of the class that file implemented.
This change makes all the test names consistently based off of the file
name they test, and also brings in the new .test convention to make
them easier to read.
Now, if you have a file like fiber.cc you want to test, you'd have a
unit test in a file called fiber.test.cc, and a test called fiber.test
which would generate a binary called fiber.test.opt, fiber.test.debug,
etc.
Change-Id: I61d59016090371a9bae72066e7473a34aecea21f
Reviewed-on: https://gem5-review.googlesource.com/c/14677
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
