Previously we did not have any documentation discussing how gem5's GTests
were built and executed. TESTING.md has thereby been updated to highlight
how this is done. These unit tests should be run prior to each new
submission to Gerrit. This has been noted in TESTING.md also.
Change-Id: If5867fa0a2e4f6ea0921191a51e779c19a28117a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21479
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@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>
ELF is, in my opinion, the most important object file format gem5
currently understands, and in ELF terminolgy the blob of data that
needs to be loaded into memory to a particular location is called a
segment. A section is a software level view of what's in a region
of memory, and a single segment may contain multiple sections which
happen to follow each other in memory.
Change-Id: Ib810c5050723d5a96bd7550515b08ac695fb1b02
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21462
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
If the %p format is used, char * arguments should be printed as the
hex value of their pointer, not as strings. Unfortunately blindly
passing them to an ostream using << will not do that. This change adds
some casting in that case to ensure that they're treated as numbers and
not as strings.
Change-Id: If02bae6d5e468b352266702fcba62b6beddffcbd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21459
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Those registers are 32-bit instead of 64 in the KVM API.
The Linux kernel 5.2 linux/Documentation/virtual/kvm/api.txt contains:
0x6020 0000 0010 00d4 FPSR 32 fp_regs.fpsr
0x6020 0000 0010 00d5 FPCR 32 fp_regs.fpcr
The register itself is 64-bit in the ARM manual, but the top 32 are
RES0.
This fixes the following error when running ARM KVM early in the
simulation:
panic: KVM: Failed to set register (0x60300000001000d4) value
(errno: 22)
Change-Id: I8fe6e12df4809992173200a42e3ce5414748bdad
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21300
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
glibc 2.30 introduced the function gettid() in sys/types.h to return the
caller's thread ID. In order to avoid conflicts, the already present
gettid() functions have been renamed to sysGettid(). This fixes a
compilation error with X86 arch.
Change-Id: I76c971465fc4b50e4decde8303185439082b2378
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21379
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When compiling using "scons build/X86/base", "error: 'tx_queue_size'
may be used uninitialized in this function" is received (cc1plus:
all warnings treated as errors). tx_queue_size is now initialized
to zero to avoid this compilation error.
Change-Id: I0e2a4fd9ad6053c4c4124c83da9a7919778bcc52
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21399
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This was to support port proxies and getInstPort and getDataPort. With
some recent upstream changes, getInstPort and getDataPort are only used
for CPU switching which we can't support (TLM ports are bound
permanently), and with the sendFunctional delegate for port proxies,
we don't need to have a traditional gem5 port lying around.
This gets rid of the "mem" port and all its plumbing.
Change-Id: Ic68a40a26b24aa05b33da0510c9f4b7621cbf578
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21048
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Originally MessageReq was intended to mark a packet as a holding a
message destined for a particular recipient and which would not
interact with other packets.
This is similar to the way a WriteReq would behave if writing to a
device register which needs to be updated atomically. Also, while the
memory system *could* recognize a MessageReq and know that it didn't
need to interact with other packets, that was never implemented.
Change-Id: Ie54301d1d8820e206d6bae96e200ae8c71d2d784
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20823
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The iris CPU model doesn't necessarily know the best way to send
functional packets (what port? what type is that port?), but only has
a generic sc_module pointer to the EVS and so can't call specialized
methods on it. There also isn't any common base class for EVSes to cast
into in a generic way.
This attribute mechanism lets the EVS set up its own sendFunctional
implementation however it needs to using facilities that are built
into generic sc_objects.
Change-Id: I69bf364908c2a5360bd6ce7d3e49ce67c6f771b0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21046
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
This attribute is to let the fast model EVS CPU find and talk to the
gem5 CPU in case it needs a pointer to one of its ThreadContexts for
instance.
Also move the code that finds the clock period attribute/event to the
constructor. gem5 guarantees that the EVS is constructed before its
pointer is passed to the iris CPU wrapper, and so the EVS will have
had a chance to install those controls if it's going to.
Change-Id: I389ef0ba0f9d528140f40444baa5091a9ec338cd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21045
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These signals come from the exported virtual subsystem and could signal
interrupts, etc. The new SignalReceiver class makes it easier to watch
those signals and perform some behavior when they change without having
to bring along a lot of systemc baggage.
Change-Id: I09651de1dd0e7340a61779aaf080c695ce299fd4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21043
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When a writeback needs to be allocated the whenReady field of the
block is not set, and therefore its access latency calculation
uses the previously invalidated value (MaxTick), significantly
delaying execution.
This is fixed by assuming that the data write portion of a write
access is done regardless of previous writes, and that only the
tag latency is important for the critical path latency calculation.
Change-Id: I739132a2deab6eb4c46d084f4ee6dd65177873fd
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20068
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Descriptions were previously printed on one line, unless explicitly broken
when writing the description of the Sim-Object. In this commit, line
wrapping is enabled when printing these descriptions. Developers, when
writing the Sim-Object descriptions, may now over multiple lines with
triple double-quotes and still have the description output correctly when
viewing the Sim-Objects within the CLI.
E.g.: X86System previously had the following load_addr_mask component which
was output as:
load_addr_mask
default: 18446744073709551615
desc: Address to mask loading binaries with, if 0, system \
auto-calculates the mask to be the most restrictive, otherwise it obeys a \
custom mask.
This was defined by the developer via:
load_addr_mask = Param.UInt64(0xffffffffffffffff,
"Address to mask loading binaries with, if 0, system "
"auto-calculates the mask to be the most restrictive, "
"otherwise it obeys a custom mask.")
This is now displayed as:
load_addr_mask
default: 18446744073709551615
desc: Address to mask loading binaries with, if 0,
system auto-calculates the mask to be the most
restrictive, otherwise it obeys a custom mask.
JiraID: Gem5-57
Built: Linux (GCC)
Tested: Ran quick tests for X86, ARM, and RISC-V
Change-Id: If012304e50af60f6ba10c1fa2b44da8bac1c09cf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21179
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Note that this changes the stat format used by the DRAM
controller. Previously, it would have a structure looking a bit like
this:
- system
- dram: Main DRAM controller
- dram_0: Rank 0
- dram_1: Rank 1
This structure can't be replicated with new-world stats since stats
are confined to the SimObject name space. This means that the new
structure looks like this:
- system
- dram: Main DRAM controller
- rank0: Rank 0
- rank1: Rank 1
Change-Id: I7435cfaf137c94b0c18de619d816362dd0da8125
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21142
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Wendy Elsasser <wendy.elsasser@arm.com>
