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>
Fast Models are models written by ARM which emulate different
components of a computer system. They can be combined into small
subsystems and then exported as systemc modules.
To enable this code, you'll need to set USE_ARM_FASTMODEL variable to
true. This CL does not include the fast models themselves, or a license
to use them or the associated tools. To build these fast models, you'll
need to set some scons variables. These variables should be set as
described in the fast model distribution.
* PVLIB_HOME
* MAXCORE_HOME
* ARMLMD_LICENSE_FILE
Some minor patches to source filesdistributed with the fast model code
may be necessary since their use of systemc is not necessarily 100%
standards compliant.
Change-Id: Id53814b95d8aa320da4d4f2159be0736fc12eb73
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20799
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Some objects need to know that we are about to dump stats to perform
prepare statistics. This is currently done by registering a callback
with the stat system. Expose this callback as a virtual method
in Stats::Group to make this pattern more convenient.
Change-Id: I5aa475b7d04c288e45f5f413ab7a1907b971dae5
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21139
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
New-world stats didn't implement the old gem5 quirk where the index of
an element in a vector of size 1 is ignored. This affects the object
path when printed in a stat file. Implement the same quirk as the
original code to make sure names of old- and new-world stats are
compatible.
Change-Id: I12696d40baaed2d0bb1ef061e87c3b1d0f4bb4b1
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21163
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
The cacheProbe() function will return the victim entry, and it gets
called for multiple times in trigger function in a single miss. This
will cause a problem when we try to add a new replacement policy to
the Ruby system. Certain policy, like RRIP, will modify the block
information every time the getVictim() function gets called. To
prevent future problems, we need to store the victim entry, so that
we only call it once in one miss.
Change-Id: Ic5ca05f789d9bbfb963b8e993ef707020f243702
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21099
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Pouya Fotouhi <pfotouhi@ucdavis.edu>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change is based on modify the way we move the AtomicOpFunctor*
through gem5 in order to mantain proper ownership of the object and
ensuring its destruction when it is no longer used.
Doing that we fix at the same time a memory leak in Request.hh
where we were assigning a new AtomicOpFunctor* without destroying the
previous one.
This change creates a new type AtomicOpFunctor_ptr as a
std::unique_ptr<AtomicOpFunctor> and move its ownership as needed. Except
for its only usage when AtomicOpFunc() is called.
Change-Id: Ic516f9d8217cb1ae1f0a19500e5da0336da9fd4f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20919
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This makes the device IntSlavePort calls back into based on a template
parameter so that IntDevice doesn't have to be in the inheritance
hierarchy to use it.
It also makes IntSlavePort inherit from SimpleTimingPort directly,
skipping over MessageSlavePort.
Change-Id: Ic3213edc9c3ed5e506ee1e9f5e082cd47d7c7998
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20820
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
