This file populated the "cxx_config_directory" map from type names to
directory entry generating types. It used a comprehensive list of
includes of all SimObject headers, and a comprehensive list of the
generating types to fill everything in.
Instead, this change creates a new singleton helper class which, when
instantiated as a static member of a CxxConfigParams subclass, will
install a pointer to a CxxConfigDirectoryEntry to that map during global
object construction time.
Also, this change renames the map to cxxConfigDirectory which is in
compliance with the style guide, and puts it behind an accessor which
returns a static variable which is the actual map. This avoids any
problems that might come from global object construction order.
Change-Id: Iaa913fbe5af1b11d90ca618e29420eeb7cb0faed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49455
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The BaseCPU type had been specializing itself based on the value of
TARGET_ISA, which is not compatible with building more than one ISA at a
time.
This change refactors the CPU models so that the BaseCPU is more
general, and the ISA specific components are added to the CPU when the
CPU types are fully specialized. For instance, The AtomicSimpleCPU has a
version called X86AtomicSimpleCPU which installs the X86 specific
aspects of the CPU.
This specialization is done in three ways.
1. The mmu parameter is assigned an instance of the architecture
specific MMU type. This provides a reasonable default, but also avoids
having having to use the ISA specific type when the parameter is
created.
2. The ISA specific types are made available as class attributes, and
the utility functions (including __init__!) in the BaseCPU class can
refer to them to get the types they need to set up the CPU at run time.
Because SimObjects have strange, unhelpful semantics as far as assigning
to their attributes, these types need to be set up in a non-SimObject
class, which is then brought in as a base of the actual SimObject type.
Because the metaclass of this other type is just "type", things work
like you would expect. The SimObject doesn't do any special processing
of base classes if they aren't also SimObjects, so these attributes
survive and are accessible using normal lookup in the BaseCPU class.
3. There are some methods like addCheckerCPU and properties like
needsTSO which have ISA specific values or behaviors. These are set in
the ISA specific subclass, where they are inherently specific to an ISA
and don't need to check TARGET_ISA.
Also, the DummyChecker which was set up for the BaseSimpleCPU which
doesn't actually do anything in either C++ or python was not carried
forward. The CPU type still exists, but it isn't installed in the
simple CPUs.
To provide backward compatibility, each ISA implements a .py file which
matches the original .py for a CPU, and the original is renamed with a
Base prefix. The ISA specific version creates an alias with the old CPU
name which maps to the ISA specific type. This way, old scripts which
refer to, for example, AtomicSimpleCPU, will get the X86AtomicSimpleCPU
if the x86 version was compiled in, the ArmAtomicSimpleCPU on arm, etc.
Unfortunately, because of how tags on PySource and by extension SimObjects
are implemented right now, if you set the tags on two SimObjects or
PySources which have the same module path, the later will overwrite the
former whether or not they both would be included. There are some
changes in review which would revamp this and make it work like you
would expect, without this central bookkeeping which has the conflict.
Since I can't use that here, I fell back to checking TARGET_ISA to
decide whether to tell SCons about those files at all.
In the long term, this mechanism should be revamped so that these
compatibility types are only available if there is exactly one ISA
compiled into gem5. After the configs have been updated and no longer
assume they can use AtomicSimpleCPU in all cases, then these types can
be deleted.
Also, because ISAs can now either provide subclasses for a CPU or not,
the CPU_MODELS variable has been removed, meaning the non-ISA
specialized versions of those CPU models will always be included in
gem5, except when building the NULL ISA.
In the future, a more granular config mechanism will hopefully be
implemented for *all* of gem5 and not just the CPUs, and these can be
conditional again in case you only need certain models, and want to
reduce build time or binary size by excluding the others.
Change-Id: I02fc3f645c551678ede46268bbea9f66c3f6c74b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52490
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, an access to an invalid address will cause GEM5 to exit with
a `!pkt.isError()` assertion failure. I was seeing this assertion while
running a baremetal RISC-V binary that faulted before the trap vector
had been configured and therefore tried to jump to address zero. With
this change we now print the invalid address and the type of access
(ifetch/load/store/amo) which makes debugging such a problem much easier.
For example, my faulting program now prints the following:
`panic: Instruction fetch ([0:0x4]) failed: BadAddressError [0:3] IF`
I also saw this assertion with a program that was dereferencing a NULL
pointer, which now prints a more helpful message:
`panic: Data fetch ([0x10:0x11]) failed: BadAddressError [10:10]`
Change-Id: Id983b74bf4688711f47308c6c7c15f49662ac495
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55203
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Port large DS read/write instructions from
https://gem5-review.googlesource.com/c/public/gem5/+/48342.
This implements the 96 and 128b ds_read/write instructions in a similar
fashion to the 3 and 4 dword flat_load/store instructions.
These instructions are treated as reads/writes of 3 or 4 dwords, instead
of as a single 96b/128b memory transaction, due to the limitations of
the VecOperand class used in the amdgpu code.
In order to handle treating the memory transaction as multiple dwords,
the patch also adds in new initMemRead/initMemWrite functions for ds
instructions. These are similar to the functions used in flat
instructions for the same purpose.
Change-Id: Iee2de14eb7f32b6654799d53dc97d806288af98f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55344
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Port the fixes for scalar source checks from arch-gcn3 at
https://gem5-review.googlesource.com/c/public/gem5/+/48344.
Scalar sources can either be a general-purpose register or a constant
register that holds a single value.
If we don't check for if the register is a general-purpose register,
it's possible that we get a constant register, which then causes all of
the register mapping code to break, as the constant registers aren't
supposed to be mapped like the general-purpose registers are.
This fix adds an isScalarReg check to the instruction encodings that
were missing it.
Change-Id: I30dd2d082a5a1dcc3075843bcefd325113ed1df6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55343
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, the test in realview64-simple-atomic-checkpoint.py runs the
default number of checkpoint cycles which is 5. Each of these cycles
takes a long time to run (approximately 5 minutes) which makes this test
take a long time to run to completion. We would get almost all of the
benefit of this test in a fraction of the time if we reduce the number
of iterations down to 3. This still has enough iterations to catch bugs
which would happen in one, a different class of bugs which happen when
checkpointing more than once, and even a third iteration for safety.
Because this test is one of the (if not the) most time consuming test in
the quick tests, reducing its length will significantly improve turn
around time when running all those tests.
That is especially valuable when running the tests multiple times to try
to iterate on a bug, or when sweeping through a series of changes trying
to identify the source of breakages. In cases where we might need to
identify failures which don't effect the end product of a series, ie where
a problem is introduced and then coincidentally fixed in a later change,
this is especially important since every individual change needs to be
checked, not just log(n) of the changes like in a binary search.
Ideally in the future we will also try to figure out why taking and
restoring from checkpoints takes so long so that each iteration of this
test is substantially less expensive. If we do that, we could consider
increasing the iteration count again.
Change-Id: Icfa2a391a4a7457d893f2063fab231d22e572deb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53123
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
When a user accidentally specifies the wrong path to a file, the
following error is received:
```
build/X86/base/loader/image_file_data.cc:111: panic: panic condition fd < 0 occurred: Failed to open file {path}.
```
For new users to gem5 this is confusing, and does not explicitly state
that the root cause of the issue is likely due to the path being
incorrect. Due to use of `panic_if`, this error was followed by a long
and unhelpful backtrace.
This patch expands the error message to state this error is typically
triggered when the specified path is incorrect. It also changes the
`panic_if` to a `fatal_if`. As noted in `src/base/logging.hh`, a
"panic() should be called when something happens that should never ever
happen", while a "fatal() should be called when the simulation cannot
continue due to some condition that is the user's fault". It is clear a
`fatal_if` is more suitable here as it is typically a user error. A
backtrace is not printed for `fatal`, only for `panic`.
Change-Id: I6e0a9bf4efb27ee00a40d77d74fd0dc99f9be4f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55183
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
Add initrd_filename and initrd_addr parameters to specify that an
initrd/initramfs should be loaded into memory from a file, just like the
DTB blob. The user must specify the initrd file, and they can specify
the initrd load address as well. However, in practice, it's expected
that the dev/machine backend will derive the initrd load address from
the dtb load address, which is how a bootloader would typically do it.
Change-Id: I6378927c2984b7ccdd1471486dd7803500ef5883
Signed-off-by: Alistair Delva <adelva@google.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54184
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a new API function, addBootData(), which allows the ports to specify
the size and load address of the initrd/initramfs via DeviceTree. This
uses the standard chosen nodes for initrd-start/initrd-end.
Update the addBootCmdline() to call addBootData() with no
initrd/initramfs so as to maintain backwards compatibility.
Change-Id: I7b1d5cf2a0b18685eaadf1d881434f3d48c45d8b
Signed-off-by: Alistair Delva <adelva@google.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54183
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are many SE mode system calls that are implemented
in src/sim/syscall_emul.cc or src/sim/syscall_emul.hh.
And they work well under X86 and ARM platforms. However,
they are not supported in se_workload.cc under the RISC-V
platform. This patch adds support for all the system calls
already implemented in syscall_emul.hh/cc to the RISC-V
platform (in arch/riscv/linux/se_workload.cc).
Change-Id: Ia47c3c113767b50412b1c8ade3c1047c894376cf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54803
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Three changes below:
1. The m_stall_time was declared as statistics::Average, but
statistics::Average uses AvgStor as storage and this works as per-tick
average stat. In the case of m_stall_time, Scalar should be used to get
the calculation right.
2. The function used to get an enqueue time was changed since the
getTime() returns the time when the message was created.
3. Record the stall time only when the message is really dequeued
from the buffer (stall time is not evaluated when the message is moved
to stall map).
Change-Id: I090d19828b5c43f0843a8b735d3f00f312c436e9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54363
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 `get_simstat` function in `src/python/m5/stats/gem5stats.py` was
returning an error when a non-Root Simobject was passed:
```
AttributeError: object 'PyTrafficGen' has no attribute 'name'
At:
build/NULL_MESI_Two_Level/python/m5/SimObject.py(1430): __getattr__
build/NULL_MESI_Two_Level/python/m5/stats/gem5stats.py(279): get_simstat
```
The issue was an assumption that SimObjects have a field `name`. They
do not. To get a SimObject's name the `get_name()` function must be
used. This patch fixes this issue.
In addition to this fix, the documentation in this function has been
improved to state more clearly what can be passed and what shall be
returned. Previously it was somewhat unclear.
Change-Id: I33538120015280bb6260ccf8eba6b75ff43d280e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54943
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
As noted here: https://gem5.atlassian.net/browse/GEM5-1133,
NVMInterface.py does not have a `controller()` function, which is used
by `configs/common/MemConfig.py` to obtain a memory controller for a
specific memory type selected. This patch adds a `controller()`
function to `NVNInterface.py` to avoid the reported error.
It should be noted that we do not enforce a rule that a memory type
must include a `controller()` function. `se.py`, and other scrips
that use `configs/common/MemConfigs.py`, should not rely on this
false assumption.
Change-Id: Ieba62f803d3b9f9c5c3c863d5a8c4ca16c5e5e82
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54923
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
There is currently a "--gold-linker" option, which tells SCons to use
the gold linker. This puts the gold linker in a special position where
it has its own command line option, and makes it impossible to
explicitly select any other linker.
This change adds a --linker option which can be set to "bfd" (the
default gnu linker), "gold" (the gnu gold linker), or "lld" which is the
clang linker. If none is specified, SCons will let the compiler fall
back to whatever its default is.
The --gold-linker option is modified so that it just sets the --linker
option for you. Because of how SCons handles adding command line
options, there isn't a good way to complain if both it and --linker is
used, nor is there a good way to warn that the user is using a
deprecated command line option. A warning is in the help text for that
option now, though.
If the gold linker is selected, this change also sets the --threads
option, and sets the --thread-count option. This tells the gold linker
to run multi-threaded to speed up linking. Apparently the gold linker
must have been built with an option that enables threading for these
options to have any effect. If threads and LTO are both enabled, the
gold linker segfaults. To avoid that problem, we don't add --threads if
LTO has been enabled.
This change also enables a new configuration, where lld, the clang
linker, can be used with gcc. Unfortunately the format of LTO
information gcc/g++ generates is not compatible with lld, and so if you
set the linker to lld and enable LTO, you'll probably get errors like
not being able to find the symbol "main".
This change also allows you to select the default gnu linker ("bfd")
when using clang, although it's not clear why you would want to do that.
Change-Id: Ib37030431527f5d0bc626e9594b2e1142df889be
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49003
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
rocBLAS builds for all targets by default, but it requires we set the
HCC_AMDGPU_TARGET env variable to all the targets we want to build for.
This change explicitly sets all the gfx versions we intend to support in
gem5, and removes the extraneous "-a all" from the install command.
Additionally, doing this allowed for DNNMark to run on gfx902.
Change-Id: Id1a00433beaa23f6935c12073d5bddc38431886b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54623
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This resource has been deprecated in favor of 'x86-ubuntu-18.04-img'. In
practise, these are the same resource (i.e., the same disk image), but
we deprecate 'x86-ubuntu-img' as 'x86-ubuntu-18.04-img' is more explicit
on what the disk image contains. Going forward we may want different
disk image resources with different Ubuntu versions, and we want it to
be clear what the user is retrieving.
Change-Id: I06b08e6b65cf431067ffda35ebd10d419068d073
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54583
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
