If given more than just its condition, gem5_assert will assume it
should act like chatty_assert.
Because we have our own custom assert now anyway, we can fold the
behavior of both into one macro and make life easier for users.
Deprecate chatty_assert.
Change-Id: I43497b5333802a265c0ad096681f64ab6f0424b1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48606
Maintainer: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The CXX config code is not entirely correct, and will fail with some of
the objects defined for systemc support. If you're going to build gem5
with --with-cxx-config, you have to also disable the systemc support.
This had been updated in the gem5_with_systemc/README file, but not in
the tlm/README file.
Change-Id: Icd933e867c5e51fe8725a4a2c0925c41675ce4fd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49453
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 will never be executed since FULL_SYSTEM is not part of the
build environment (and hasn't been for many years), and on top of that,
this declaration redundantly (and incompletely) tries to set up the
X86PagetableWalker that the ISA already sets up.
Change-Id: I40cffbd7f60c1f741b1a14d9009f80185c9ce28c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49405
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
These now instantiate Builders for the protobuf .cc and .h files of the
right flavors, and install the .cc files as sources.
Also, this sets up the builder for .cc files so that it will know how to
build those files from .proto using the protobuf compiler. This is
optional, but will make it possible to pass .proto files in place of .cc
files or even object files as sources for other builders, and for scons
to figure out what chain of rules to use to get the desired results.
This is a step towards handing over more responsibility to scons and
eliminating at least some of our bespoke build code.
Change-Id: I7188a0917e999ad9148f7079830b2c26bcd563db
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48134
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Disable warnings when targets can be built with multiple environments
but with the same actions. This can happen intentionally if, for
instance, a generated source file is used to build object files in
different ways in different environments, but generating the source
file itself is exactly the same. This can be re-enabled from the
command line if desired.
Change-Id: I426ca3331267f026553c9a2bccc79494cace8109
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48133
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The "predicate"s for reading/writing some condition code registers were
written with constants which were built up from other constants which
represent individual bits in the condition code register. There are
existing constants which already exactly match those sets of bits, so we
can just use those instead of building up the same thing in-situ.
Change-Id: Iab5a5de04d0fd858414451531a357770ca9fde14
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49244
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Because MediaOps have two sizes, one for sources and one for
destinations, it does not have a single dataSize member to set the size
of its operands. This was difficult to correct at the time, so a
dataSize member was created which was fixed at 0, and the instructions
themselves would use srcSize and destSize internally to do the actual
computation.
That causes problems when tracing, since the printReg function needs to
know what size to use to print some registers properly, specifically
integer registers.
To now fix that problem, some SFINAE constructors have been added which
will either pass through a dataSize member if one exists, or pass
through a pointer to the instruction itself so that operand index
selector class can pick out the member that makes sense for it (destSize
for DestOp, srcSize for Src1Op and Src2Op).
Change-Id: I6b8259a5ab27f809b81453bcf987cc6d1be4811a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49203
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
These methods are all identical now. The O3 versions can all be
consolidated into a single method. For the checker CPU, they can
actually be eliminated entirely, and the result queue's "emplace()"
method can be used to add items using less text than just calling the
original helper method.
Change-Id: Ifaeb3beeea257c8bbf951ee1dd8d2d5fd8bb3964
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49128
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These *used* to have a source register which was the syscall number.
That was not an actual property of the instruction, it was a property of
the syscall mechanism in Linux which had leaked into the implementation
of the instructions themselves.
That was corrected by removing that source register and letting the
syscall handling layer figure out which system call to invoke.
Unfortunately the SyscallInst format wasn't also updated, and when
printing the disassembly for those instructions, it would try to print
that source register. That instruction doesn't bother to set up a source
operand array since it doesn't actually have any, so that ended up
accessing random memory.
Change-Id: I20890ad69605983305a13f414ca59a5fa35d4d06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49183
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The function will return the absolute path of the gem5 repo
hosting the m5 library.
One of the use of this helper is to effectively refer/import
gem5 modules from EXTRAS repositories.
If I wanted to import the Ruby module from configs/ruby I could
do that with:
from m5.util import addToPath, repoPath
configs_path = os.path.join(repoPath(), configs)
addToPath(configs_path)
from ruby import Ruby
This isn't an out of tree scripts utility only: most of our configs are
currently relying on doing relative backward imports and could be ported
to use the repoPath utility:
addToPath(../..) is quite a common pattern
This makes the dependencies difficult to read/track and a bit fragile
as it all relies on the relative position between modules.
Change-Id: I26f6ef34b44f20903cc1b6248330b6156378f40b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49083
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Track structured data related to different binary flavors (opt, debug,
etc), using a class instead of various lists, etc. Also use a loop to
set up SCons environments to build these binaries instead of a spelled
out loop.
Change-Id: Ie35a914ab79342190e4cdc27a945a0fecd54a476
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48130
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
This function used makeAtomicOpFunctor to create a unique_ptr which
pointed to an AtomicOpFunctor *, which it immediately extracted with
.get(). Then since the temporary unique_ptr went out of scope, it
deleted the AtomicOpFunctor which it just returned a pointer to.
Instead, that function should create a local unique_ptr to pass
ownership of the object off to. It will still be cleaned up when it
goes out of scope, but not before it's done being used.
Change-Id: I74a0bcbb719a78a3e9ec8cb2ea5aa15120da0456
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49023
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Kyle Roarty <kyleroarty1716@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The SourceFile.filename property dynamically calculated the str()
conversion of self.tnode. Since self.tnode shouldn't be changed, it
doesn't seem useful to calculate that value over and over, especially
since it adds some extra indirection and magic to something that's
really pretty simple.
Change-Id: Ia0e1e8f4b0c019a026a08b5c2730d93c66de8190
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48123
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The build for .fast was set up to produce a stripped executable, and the
unstripped executable was instead named .fast.unstripped. I think the
assumption that a stripped executable is faster than an unstripped
executable is flawed, since the parts of the binary that are removed,
debug symbols, are not loaded into memory anyway, so while the program
is executing it shouldn't be any different or take up any additional
memory. This also made .fast a special case compared to the other build
types, like .opt, .debug, etc.
Instead, this change makes .fast unstripped like all the other binaries,
and also makes it possible to request a stripped version of *any* binary
the build can produce with a .stripped suffix.
Change-Id: I2de82e0951d9f41c30594f32fba50acdd14ed69c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48120
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
