This change creates a distinction between object files which hold
executable code, and flat files which don't. The first type of files
have entry points, symbols, etc., while the others are just blobs which
can be shoved into memory. Rather than have those aspects but stub
them out, this change creates a new base class which simply doesn't
have them.
This change also restructures the ELF loader since it's main function
was quite long and doing multiple jobs.
It stops passing the architecture and operating system to the
ObjectFile constructor, since those might not be known at the very top
of the constructor. Instead, those default to Uknown*, and then are
filled in in the constructor body if appropriate. This removes a lot
of plumbing that was hard to actually use in practice.
It also introduces a mechanism to collect generic object file formats
so that they can be tried one by one by the general createObjectFile
function, rather than listing them all there one by one. It's unlikely
that new types of object files will need to be added in a modular way
without being able to modify the core loader code, but it's cleaner to
have that abstraction and modularization like is already there for
process loaders.
Finally, to make it possible to share the code which handles zipped
files for both true object files and also files which will be loaded
into memory but are just blobs, that mechanism is pulled out into a
new class called ImageFileData. It holds a collection of segments
which are set up by the object file and may refer to regions of the
original file, buffers maintained elsewhere, or even nothing to support
bss-es. shared_ptr is used to make it easier to keep track of that
information without having to do so explicitly or worry about deleting
a buffer before everyone was done using it.
Change-Id: I92890266f2ba0a703803cccad675a3ab41f2c4af
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21467
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
According to the Intel SDM, no instruction following an LFENCE can begin
execution until after the LFENCE has executed. (This is
less strict than an actual serializing instruction, such as CPUID.)
Serializing instructions (per intel SDM Volume 3A Chapter 8.3) ensure
that no future instruction is fetched until after the serializing
instruction is completed.
By contrast, LFENCE (and other memory-ordering instructions) allows
future instructions to have been fetched; it just prohibits them from
being executed.
Change-Id: If89fcb552192326ab69a581f57d71c95cf5d90e7
Signed-off-by: Isaac Richter <isaac.richter@rochester.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/10321
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is carving out a portion of VExpress_GEM5 memory for the
bootloader. Prior to this patch this was only happening
conditionally/dynamically via the setupBootLoader call. With this patch
the region is always present and the setupBootLoader doesn't instantiate
memory, it is only setting up some bootloader parameters.
Change-Id: Iaa5cdf471b14e8faa37353a25631bf7c6fc64afc
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21604
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This queue was set up to allow triggering events based on the total
number of instructions executed at the system level, and was added in
a change which added a number of things to support McPAT. No code
checked into gem5 actually schedules an event on that queue, and no
code in McPAT (which seems to have gone dormant) either downloadable
from github or found in ext modify gem5 in a way that makes it use
the instEventQueue.
Also, the KVM CPU does not interact with the instEventQueue correctly.
While it does check the per-thread instruction event queue when
deciding how long to run, it does not check the instEventQueue. It will
poke it to run events when it stops for other reasons, but it may (and
likely will) have run beyond the point where it was supposed to stop.
Since this queue doesn't seem to actually be used for anything, isn't
being used properly in all cases anyway, and adds overhead to all the
CPU models, this change eliminates it.
Change-Id: I0e126df14788c37a6d58ca9e1bb2686b70e60d88
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21783
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Tiago Mück <tiago.muck@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The devices which host an IntMasterPort are very specific to x86 at the
moment, but the ports don't have to be. This change moves
responsibilities around so that the x86 specific aspects are handled
in the device, and the ports themselves are ISA agnostic.
Change-Id: I50141b66895be7d8f6303605505002ef424af7fd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20827
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There is no interrupt response message, and so no need for a function
which would construct one. The other functions which construct the
request can be consolidated since the work being done by each is
incremental. The template parameters can be used to support multiple
types and offsets in a single function, and since that function also
doesn't have to do much work, it makes sense to do everything in one
shot.
Change-Id: I41b202a263a697c5ada6817f3ab2a4728281b894
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20826
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
The unconnected CPU ports/sockets still need to be connected for TLM to
be happy, so this change also adds a terminator module which finds all
unbound sockets, creates pair sockets for them to connect to, binds
everything together, and implements the target interface with a dummy
stub that will complain and crash gem5 if it ever gets called.
This will allow us to use the same GIC model to connect an arbitrary
number of cores, up to the architected limit of 256.
Change-Id: Iaa83fe4f023217dc91a3734b31f764fc4176130e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21500
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Modify second chance replacement policy so that entries are inserted
without a second chance. Previously, the second chance bit was set
to true when a cache line was inserted. So the cache line would gain
its second chance when inserting. This is wrong because the cache
block will only get a second chance when it hits.
Here's a quoted citation for the second chance replacement policy:
"Whenever the algorithm examines a page entry, it extracts the associated
usage bit and enters it into the high-order position of a k-bit shift
register after shifting the contents of the register one bit-position
lower. Then if the shift register is nonzero, the page is retained; if the
shift register is zero, the page is replaced by the new page. In either
case the usage bit for the page is turned off and the circular list
pointer is advanced."
(A Paging Experiment with the Multics System, FJ Corbato, 1968)
Change-Id: I0d07e56aa16c67dd36e0d490c3f457f91e46f320
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20882
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
A memory image can be described by an object file, but an object file
is more than a memory image. Also, it makes sense to manipulate a
memory image to, for instance, change how it's loaded into memory. That
takes on larger implications (relocations, the entry point, symbols,
etc.) when talking about the whole object file, and also modifies
aspects which may not need to change. For instance if an image needs
to be loaded into memory at addresses different from what's in the
object file, but other things like symbols need to stay unmodified.
Change-Id: Ia360405ffb2c1c48e0cc201ac0a0764357996a54
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21466
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Add support in Ruby to use all replacement policies in Classic.
Furthermore, if new replacement policies are added to the
Classic system, the Ruby system will recognize new policies
without any other changes in Ruby system. The following list
all the major changes:
* Make Ruby cache entries (AbstractCacheEntry) inherit from
Classic cache entries (ReplaceableEntry). By doing this,
replacement policies can use cache entries from Ruby caches.
AccessPermission and print function are moved from
AbstractEntry to AbstractCacheEntry, so AbstractEntry is no
longer needed.
* DirectoryMemory and all SLICC files are changed to use
AbstractCacheEntry as their cache entry interface. So do the
python files in mem/slicc/ast which check the entry
interface.
* "main='false'" argument is added to the protocol files where
the DirectoryEntry is defined. This change helps
differentiate DirectoryEntry from CacheEntry because they are
both the instances of AbstractCacheEntry now.
* Use BaseReplacementPolicy in Ruby caches instead of
AbstractReplacementPolicy so that Ruby caches will recognize
the replacement policies from Classic.
* Add getLastAccess() and useOccupancy() function to Classic
system so that Ruby caches can use them. Move lastTouchTick
to ReplacementData struct because it's needed by
getLastAccess() to return the correct value.
* Add a 2-dimensional array of ReplacementData in Ruby caches
to store information for different replacement policies. Note
that, unlike Classic caches, where policy information is
stored in cache entries, the policy information needs to be
stored in a new 2-dimensional array. This is due to Ruby
caches deleting the cache entry every time the corresponding
cache line get evicted.
Change-Id: Idff6fdd2102a552c103e9d5f31f779aae052943f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20879
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The interpreter is a separate object file, and while it's convenient to
hide loading it in the code which loads the main object file, it breaks
the conceptual abstraction since you only asked it to load the main
object file.
Also, this makes every object file format reimplement the idea of
loading the interpreter. Admittedly only ELF recognizes and sets up
an interpreter, but other formats conceptually could too.
This does move that limitted hypothetical redundancy out of the object
file formats and moves it into the process objects, but I think
conceptually that's where it belongs. It would also probably be pretty
easy to add a method to the base Process class that would handle
loading an image and also the interpreter image.
This change does not (yet) separate reading symbol tables.
Change-Id: I4a165eac599a9bcd30371a162379e833c4cc89b4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21465
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
The ObjectFile class has hardcoded assumptions that there are three
segments, text, bss and data. There are some files which have one
"segment" like raw files, where the entire file's contents are
considered a single segment. There are also ELF files which can have
an arbitrary number of segments, and those segments can hold any
number of sections, including the text, data and/or bss sections.
Removing this assumption frees up some object file formats from having
to twist themselves to fit in that structure, possibly introducing
ambiguities when some segments may fulfill multiple roles.
Change-Id: I976e06a3a90ef852b17a6485e2595b006b2090d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21463
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
This lets us avoid having to have two levels of bridging and twice as
many ports on both the CPU and GIC side. The direct communication ports
can be instantiated and connected using array syntax, where the bridges
require instantiating each bridge individually and wiring them up one
at a time with a lot of boilerplate/duplicate code.
Change-Id: I815ee47bcd19994e46a5220e0c23e89c497d7aa5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21050
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
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>
