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>
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>
The 'resources.json' file in gem5 resources is used to lookup resources.
The stdlib resource downloader was hardcoded to the 'resources.json'
stored in the gem5 resources stable branch. This change allows the gem5
downloader to obtain the specific resources.json.
Change-Id: Ie119ed9326b359055bf5bc347ca89336a5cc2e5d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54466
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Because the python environment may already be up and running by the time
static initializers are run, specifically when gem5 is built as a
library and loaded with dlopen, we can't rely on all of the objects
declaring python initialization callbacks having been constructed by the
time the code which would execute them runs.
To address that problem, this change keeps track of whether the
initialization has already happened when a callback is installed, and if
so, runs the callback immediately.
The original implementation also had users install callbacks by
overriding a virtual function in the PythonInitFunc class, and then
statically allocating an instance of that subclass so its constructor
would be called at initialization time. Calling the function manually if
initialization has already happened won't work in that case, because you
can't call a virtual function from a constructor and get the behavior
you'd want.
Instead, this change makes the PythonInitFunc wrap the actual callback
which is outside of the structure itself. Because the callback is not a
virtual function of PythonInitFunc, we can call it in the constructor
without issue.
Also, the Callback type has to be a bare function pointer and not a
std::function<...> because the argument it takes is a pybind11::module_
reference. Pybind11 sets the visibility of all of its code to hidden to
improve binary size, but unfortunately that causes problems when
accepting one as an argument in a publically accessible lambda in g++.
clang doesn't raise a warning, but g++ does which breaks the build. We
could potentially disable this warning, but accepting a function pointer
instead works just as well, since captureless lambdas can be trivially
converted into function pointers, and they don't seem to upset g++.
Change-Id: I3fb321b577090df67c7be3be0e677c2c2055d446
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54325
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc testing framework is not used regularly, and had bit rot and
stopped working. This change updates it so that it runs again, and all
previously passing tests pass again.
These changes were mostly in the related SConscript now that top level
targets are built a little differently and that the gem5 shared library
is no longer stored in a special construction environment variable.
verify.py also needed to be updated since warn() and info() lines now
have file and line number information in them, throwing off pre diff
filtering of gem5 outputs.
Change-Id: Ifdcbd92eab8b9b2168c449bfbcebf52dbe1f016a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54324
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The previous incarnation of this support used faults to make the CPU
reexecute the system call instruction again and again to prevent
emulating/passing through blocking system calls from blocking gem5 as
a whole. That support was accidentally removed a while ago. This new
version suspends the thread context executing the system call, and
periodically wakes it up to retry using a periodically scheduled event.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1123
Change-Id: I155fa8205d7ea45e3d102216aeca6ee1979a522f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54205
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than make each ISA include boilerplate to ignore a
SyscallReturn's value when it's marked as suppressed or needing a retry,
put that code into the SyscallDesc::doSyscall method instead.
That has two benefits. First, it removes a decent amount of code
duplication which is nice from a maintenance perspective. Second, it
puts the SyscallDesc in charge of figuring out what to do once a system
call implementation finishes. That will let it schedule a retry of the
system call for instance, without worrying about what the ISA is doing
with the SyscallReturn behind its back.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1123
Change-Id: I76760cba75fd23e6e3357f6169c0140bee3f01b6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54204
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
