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>
When remote GDB attaches to gem5, handle the initial communication
(`qSupported` and alike) right away instead of scheduling a `DataEvent`
and firing the simulation loop in hope that GDB will be quick enough to
send initial packets before instructions are dispatched.
This requires attach() to be always called at instruction boundary
to make it safe to interact with the rest of gem5.
When `--wait-gdb` is used, connect() is called from workflow startup,
therefore on an instruction boundary and therefore needs not special
handling.
To handle case the GDB connects while simulation is already running,
we arrange (new) assynchronous IncommingConnectionEvent on listening
socket that, when there's a new connection being made, *only* schedules
*synchronous* ConnectEvent that handles the rest, *including* calling
an accept() on listening socket. This way it is safe to process commands
in attach().
In order to make the code more systematic and easier to understands,
detach() is also made to be called only synchronously (that is, at
intruction boundary). Asynchronous events and event handlers are
prefixed with "incoming".
This seems to fix the race described in 44612 [1]
[1]: https://gem5-review.googlesource.com/c/public/gem5/+/44612
Change-Id: I33b2922ba017205acabd51b6a8be3e6fb2d6409a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48182
Reviewed-by: Boris Shingarov <shingarov@labware.com>
Maintainer: Boris Shingarov <shingarov@labware.com>
Tested-by: kokoro <noreply+kokoro@google.com>
At the moment the ITLBI and DTLBI operations where implicitly
implemented as generic TLBIs
e.g:
* DTLBIASID, ITLBIASID = TLBIASID
This was possible as a single TLB was either an instruction TLB
or a data TLB and no generic/shared TLB option was available.
In other words, an ITLBI Op to an ITB was invalidating all entries
as we were sure the ITB was not containing data entries.
With shared TLBs, this doesn't hold true and we need to explicitly
implement I/DTLBIs
JIRA: https://gem5.atlassian.net/browse/GEM5-790
Change-Id: I39a4add7674f6008dacaedfd1fd90560d264048e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48148
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Ruby assumes protocols use directory controllers as memory interface.
Thus, recvAtomic() uses the machine type of directory when it calls
mapAddressToMachine(). However, it doesn't work for CHI since
CHI does not use directory controllers as memory controller interface.
Therefore, the code was modified to check which controller type is used
for memory interface between MachineType_Directory and
MachineType_Memory, which is used for CHI.
Change-Id: If35a06a8a3772ce5e5b994df05c9d94c7770c90d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48403
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Now all occurances of the THE_ISA macro which were being used to check
for anything other than the NULL_ISA have been eliminated. We still need
to be able to check whether the current ISA is the null ISA, but we
don't want to let any preprocessor checks back in which are based on
what the current ISA is.
This change removes the THE_ISA macro, and replaces it with IS_NULL_ISA
which evaluates to 1 if the ISA is null, and 0 if it isn't.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1060
Change-Id: Iec146b40d8cab846dae03e15191390f754f2b71b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48709
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
g++ 11.1 has a false positive in the systemc kernel for
free-nonheap-object which breaks the build. The check sees that an
EventWrapper is part of the systemc scheduler object, and doesn't
realize that it was *not* set to autodelete, and so would *not* delete
itself (as part of the scheduler) when it is descheduled.
Change-Id: Ia9f48f2113e8c165923e55d7db1442b11bb6a2e8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48646
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The ISAs we support today mostly have a micropc, whether that's used
very heavily like on x86, or sparsely like on ARM, RISCV or SPARC. Only
MIPS and POWER don't currently use a micropc, and neither of those is
performance tuned to the point where adding some size to the PC object
should make a meaningful difference.
Because most ISAs already have a micropc anyway, and some minimal part
of managing the micropc has to be part of the guaranteed interface so
that the CPUs can work, it's a small step to make the micropc more
completely part of the base class.
This change also makes uReset part of the guaranteed interface so we can
get rid of an #if THE_ISA == in the minor CPU.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1060
Change-Id: Ide55a8feaee0bd5fff1d7ec05f95ad30a496b196
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48704
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The CpuModel class looks like it was originally intended to hold a lot
more information that it does now, which is just the name of a CPU, and
whether it should be enabled by default. All the built in configs in
build_opts already explicitly list a set of CPUs, and CPUs should not,
generally speaking, be enabled by default, since they almost always need
to be specifically supported by an ISA. This is mutual, since usually
ISAs definitions are not quite correct or complete, and this is often
exposed by plugging them into different, and/or more complex CPU models
which stress those short comings.
This change drops the idea of a "default" CPU, and since the only thing
being tracked at this point is a list of CPUs, it turns CpuModel() into
a simple function which adds a name to a set of supported CPUs.
Change-Id: Id7475d5dc8548802b5253f79839da8c76ef4d165
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48963
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As unittest.TextTestRunner().run(suite) doesn't exit the script,
it won't set the exit code, even when some tests are failing.
This means testlib is always interpreting those unittests as passing
even when there are failures.
With this patch we are propagating the error to our CI system (testlib)
Change-Id: I63b7622661a19a9b40243d13b7391e510c2007d4
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48969
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
