Age | Commit message (Collapse) | Author |
|
Change-Id: Iadf56e4e742506af7ae4b617d2dc5a56439aa407
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24188
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The x86 version doesn't do anything x86 specific, and so can be used
generically in sim/pseudo_inst.(hh|cc)
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I46c2a7d326bd7a95daa8611888051c180e92e446
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23177
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The logic that determines which syscall to call was built into the
implementation of faults/exceptions or even into the instruction
decoder, but that logic can depend on what OS is being used, and
sometimes even what version, for example 32bit vs. 64bit.
This change pushes that logic up into the Process objects since those
already handle a lot of the aspects of emulating the guest OS. Instead,
the ISA or fault implementations just notify the rest of the system
that a nebulous syscall has happened, and that gets propogated upward
until the process does something with it. That's very analogous to how
a system call would work on a real machine.
When a system call happens, the low level component which detects that
should call tc->syscall(&fault), where tc is the relevant thread (or
execution) context, and fault is a Fault which can ultimately be set
by the system call implementation.
The TC implementor (probably a CPU) will then have a chance to do
whatever it needs to to handle a system call. Currently only O3 does
anything special here. That implementor will end up calling the
Process's syscall() method.
Once in Process::syscall, the process object will use it's contextual
knowledge to determine what system call is being requested. It then
calls Process::doSyscall with the right syscall number, where doSyscall
centralizes the common mechanism for actually retrieving and calling
into the system call implementation.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I937ec1ef0576142c2a182ff33ca508d77ad0e7a1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23176
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
|
|
Setting syscall args isn't really something we need to do in gem5,
since that will be taken care of by the code actually calling the
syscall. We just need to be able to retrieve the value it put there.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I0bb6d5d0207a7892414a722b3788cb70ee509582
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23174
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
In Alpha and MIPS, the argc and argv values should be in what happens
to be the first and second syscall argument registers, but that's not
by definition. The process objects of both those ISAs know what
registers to use intrinsically, so there's also no reason to call out
to a helper method which acts as a part of the Process's interface to
the rest of gem5.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: Id8fa38ab1fc2ac6436e94ad41303439973fded10
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23173
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These namespaces were used to set up an environment/context where there
was an implicit guest namespace. This is an issue when there may be
multiple guest endiannesses which might be different. In cases where
we don't know what the guest endianness is, we can't rely on it being
an implicit part of our context since that would be ambiguous. In cases
where we do know, for instance in ISA specific code, we can just use
the endianness specific version that's appropriate for that context.
This also (somewhat) removes the assumption that there is a single
endianness that applies for a particular ISA. Practically speaking this
assumption will probably still stand though, since there would likely
be a non-trivial performance penalty to apply a configurable endianness
instead of a fixed one the compiler can optomize/remove.
Change-Id: I2dff338b58726d724f387388efe32d9233885680
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22374
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Rather than using TheISA to pick an endian conversion function, we can
have a version defined for big and little endian and call the right one
from the ISA code.
Change-Id: I5014504968952e21abff3c5f6cbe58ca24233f33
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22373
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
We already know what endianness to use from within MIPS.
Change-Id: Ic4cd295a7a66c4c8ef55ebcf976fe6637567391f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22369
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
It doesn't matter if the bytes are converted before or after they're
fed into the decoder. The ISA already knows what endianness to use
implicitly, and this frees the CPU which doesn't from having to worry
about it.
Change-Id: Id6574ee81bbf4f032c1d7b2901a664f2bd014fbc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22343
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Change-Id: I5cf4291b19dd2d2bdbbf145ad8e00994fabf5547
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22366
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
That way the syscall implementations won't have to find the right
endianness to use on their own, typically by referring to TheISA.
Change-Id: I186b2f419d5dbee72cc9b5abce7356f3143f0c83
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22363
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The consolePanicEvent pointer and addConsoleFuncEvent template were
inherited from Alpha and were not used (and probably make no sense) for
MIPS or RISCV which (to my knowledge) don't have the idea of a
"console" binary.
Change-Id: I109b866a65f69c7334062f7304c7b18acc51d99d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21782
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
This abstraction will allow scheduling PCEvents for a particular
ThreadContext, all contexts on a CPU, all contexts in a system, etc.,
and delegates scheduling and removing events to each particular scope.
Right now the PCEventQueue is the only implementor of the PCEventSCope
interface.
Change-Id: I8fb62931511136229915c2e19d36aae7ffdec9df
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22099
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
That abstracts the ISA further from the CPU, getting us a small step
closer to being able to build in more than one ISA at a time.
Change-Id: Ibf7e26a3df411ffe994ac1e11d2a53b656863223
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20831
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
This code was originally in the ObjectFile class, but not all object
files will become Processes. All Processes will ultimately come from
ObjectFiles though, so it makes more sense to put that class there.
Change-Id: Ie73e4cdecbb51ce53d24cf68911a6cfc0685d771
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21468
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.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>
|
|
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>
|
|
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>
|
|
These two functions were performing the same function but had two
different names for historical reasons. This change merges them
together, keeping the getVirtProxy name to be consistent with the
getPhysProxy method used to get a non-translating proxy port.
Change-Id: Idd83c6b899f9343795075b030ccbc723a79e52a4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18581
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Al(most) all of the interesting differences between the two classes
have been removed. There are some control methods which are still
specific to each type which may require treating them as their true
type, but most code that consumes them doesn't need to worry about
which is which.
Change-Id: Ie592676f1e496c7940605b66e55cd7fae18e59d6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18577
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
This expands those functions into code which extracts the virt proxy
and then uses the appropriate method on it. This has two benefits.
First, the Copy* functions where mostly redundant wrappers around the
methods the proxy port already had. Second, using them forced a
particular port which might not actually be what the user wanted.
Change-Id: I62084631dd080061e3c74997125164f40da2d77c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18575
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Set the default release to that single value for all ISAs.
glibc has checks for the kernel version based on uname, and refuses
to start any syscall emulation programs if those checks don't pass with
error:
FATAL: kernel too old
The ideal solution to this problem is to actually implement all missing
system calls for the required kernel version and bumping the release
accordingly.
However, it is very hard to implement all missing syscalls and verify
compliance.
Previously, we have simply bumped the version manually from time to
time when major glibc versions started breaking.
This commit alleviates the problem in two ways.
Firstly, having a single kernel version for all versions means that it is
easier to bump all versions at once.
Secondly, it makes it is possible to set the release with a parameter,
which in turn can be set from the command line with:
se.py --param 'system.cpu[:].workload[:].release = "4.18.0"'
Change-Id: I9e3c31073bfe68735f7b0775c8e299aa62b98222
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17849
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Change-Id: Ia73b2d86a10d02fa09c924a4571477bb5f200eb7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18572
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
The system calls had four parameters. One of the parameters
is ThreadContext and another is Process. The ThreadContext
holds the value of the current process so the Process parameter
is redundant since the system call functions already have
indirect access.
With the old API, it is possible to call into the functions with
the wrong supplied Process which could end up being a confusing
error.
This patch removes the redundancy by forcing access through the
ThreadContext field within each system call.
Change-Id: Ib43d3f65824f6d425260dfd9f67de1892b6e8b7c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12299
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Change-Id: Icae6430a210076117cf2ceadce52d6efbe58a5f3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18586
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
We know for sure what the ISA is, so there's no need for the
indirection.
Change-Id: I73ff04c50890d40a4c7f40caeee746b68b846cb3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18488
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
These accessors can be implemented as helper functions within MIPS
without having to plumb them through a bunch of common interfaces.
There are a few problems with the way they were implemented which are
carried forward to this new implementation as well. That includes
hiding the register accesses from the ISA parser and therefore the
CPU's dependency tracking, potentially panicing or accessing a non
existent thread based on a possible set of input values, and modifying
register values even if an instruction is being executed speculatively.
Fixing these problems would be fairly involved and require changing how
dependencies are tracked in all the CPUs so that they can act across
threads, and also how registers are handled in the ISA description
itself.
The original implementation just punted on making this work in CPUs
other than the minor CPU (and potentially one or more CPU models that
were not and/or are not in the code base). Where as that implementation
might have paniced if these methods were called, this will attempt to
work, but may have incorrect behavior based on the limitations
described above. I'd consider this an acceptable tradeoff, at least for
the time being.
Change-Id: I94adceafb9812a8641c76ea3518c3285c31baf51
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18435
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The AuxVector type has a bunch of accessors which just give access to
the underlying variables through references. We might as well just make
those members accessible directly.
Also, the AuxVector doesn't need to handle endianness flips itself. We
can tell the byteswap mechanism how to flip an AuxVector, and let it
handle that for us.
This gets rid of the entire .cc file which was complicated by trying
to both hide the ISA specific endianness translations, and instantiate
templated functions in a .cc.
Change-Id: I433cd61e73e0b067b6d628fba31be4a4ec1c4cf0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18373
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
These selected their behavior based on ifdefs and had to be disabled
when on the NULL ISA. The versions which take an explicit endianness
have been renamed to just read/write instead of readGtoH and writeHtoG
since the direction of the translation is obvious from context.
Change-Id: I6cfbfda6c4481962d442d3370534e50532d41814
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18372
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Added consistency in the DEBUG message form, to allow a better parsing.
Fixed sn/tid type parameter.
Removed some annoying newlines
Change-Id: I4761c49fc12b874a7d8b46779475b606865cad4b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17248
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
The importer in Python 3 doesn't like the way we import SimObjects
from the global namespace. Convert the existing SimObject declarations
to import from m5.objects. As a side-effect, this makes these files
consistent with configuration files.
Change-Id: I11153502b430822130722839e1fa767b82a027aa
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15981
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
|
|
Change-Id: I7155915fccdec1d9f116f2a8617474188a91165b
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/16302
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Most architectures weren't using the CCReg type, and in x86 and arm
it was already a uint64_t.
Change-Id: I0b3d5e690e6b31db6f2627f449c89bde0f6750a6
Reviewed-on: https://gem5-review.googlesource.com/c/14515
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I764f6eea214ba4e03cc0fe19a21abcb0ebd04408
Reviewed-on: https://gem5-review.googlesource.com/c/14462
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Now that there's no plain FloatReg, there's no reason to distinguish
FloatRegBits with a special suffix since it's the only way to read or
write FP registers.
Change-Id: I3a60168c1d4302aed55223ea8e37b421f21efded
Reviewed-on: https://gem5-review.googlesource.com/c/14460
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Latest-gen. vector/SIMD extensions, including the Arm Scalable Vector
Extension (SVE), introduce the notion of a predicate register file.
This changeset adds this feature across architectures and CPU models.
Change-Id: Iebcadbad89c0a582ff8b1b70de353305db603946
Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13715
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
This type is no longer used since FP registers are accessed as integer
bit patterns.
Change-Id: I1070f9443d6247165fd64c6bc041811c28287e9f
Reviewed-on: https://gem5-review.googlesource.com/c/14459
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These values are all basic integers (specifically uint64_t now), and
so passing them by const & is actually less efficient since there's a
extra level of indirection and an extra value, and the same sized value
(a 64 bit pointer vs. a 64 bit int) is being passed around.
Change-Id: Ie9956b8dc4c225068ab1afaba233ec2b42b76da3
Reviewed-on: https://gem5-review.googlesource.com/c/13626
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
Fix poll so that it will use the syscall retry capability
instead of causing a blocking call.
Add the accept and wait4 system calls.
Add polling to read to remove deadlocks that occur in the
event queue that are caused by blocking system calls.
Modify the write system call to return an error number in
case of error.
Change-Id: I0b4091a2e41e4187ebf69d63e0088f988f37d5da
Reviewed-on: https://gem5-review.googlesource.com/c/12115
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
|
|
The ISA specific types can thus be phased out.
Change-Id: I8ea531a099fad140a4ec9c91cd972fe044111d60
Reviewed-on: https://gem5-review.googlesource.com/c/13623
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Use the binary accessors instead.
Change-Id: Iff1877e92c79df02b3d13635391a8c2f025776a2
Reviewed-on: https://gem5-review.googlesource.com/c/14457
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Neither assert(0) nor assert(false) give any hint as to why control
getting to them is bad, and their more descriptive versions,
assert(0 && "description") and assert(false && "description"), jury
rig assert to add an error message when the utility function panic()
already does that directly with better formatting options.
This change replaces that flavor of call to assert with panic, except
in the actual code which processes the formatting that panic uses (to
avoid infinitely recurring error handling), and in some *.sm files
since I don't know what rules those have to follow and don't want to
accidentaly break them.
Change-Id: I8addfbfaf77eaed94ec8191f2ae4efb477cefdd0
Reviewed-on: https://gem5-review.googlesource.com/c/14636
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
This makes them more consistent with the other architectures, helping
to facilitate having a single, unified type across ISAs in the future.
Change-Id: I65efb10e39d453281b8429eeedbb46fa6b023a2b
Reviewed-on: https://gem5-review.googlesource.com/c/13620
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
For operands which default to uw (uint32_t), there's no reason to
explicitly specify that all over the place. Also, when assigning to a
32 bit value which is supposed to be the full width of the resulting
register, there's no reason to override the value to be signed. If the
value is expanded into a larger value, then extra bits may get set
unintentionally through sign extension. Even if an instruction
produces a value which should be interpreted as signed, it will still
only produce a value of a certain predefined width, even if that answer
ends up stored in a larger variable.
Change-Id: I048d68c5dd08a1d40e8117ae9d36d70e05ec21c8
Reviewed-on: https://gem5-review.googlesource.com/c/13618
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The IntReg type is 32 bits, and using it to cast the syscall return
value is appropriate, but we're attempting to get rid of the ISA
specific register types.
Change-Id: I42496dd2cc086a6b718e1ce087fef81bb897d02f
Reviewed-on: https://gem5-review.googlesource.com/c/13619
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
This type is defined for all the ISAs but isn't used by anything.
Change-Id: I659a0c5abc7883d82fedd1cac2cd103612d315c8
Reviewed-on: https://gem5-review.googlesource.com/c/13539
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
We know data is little endian, so we can use those accessors
explicitly.
Change-Id: I6220a543686b1d45d26973391b028dc04ce85dd2
Reviewed-on: https://gem5-review.googlesource.com/c/13460
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The AuxVector class is responsible for holding Process data.
The data that it holds is normally setup by an OS kernel in
the process address space. The purpose behind doing this is
to pass in information that the process will need for various
reasons. (Check out the enum in the header file for an idea of
what the AuxVector holds.)
The AuxVector struct was changed into a class and encapsulation
methods were added to protect access to the member variables.
The host ISA may have a different endianness than the simulated
ISA. Since data is passed between the process address space and
the simulator for auxiliary vectors, we need to worry about
maintaining endianness for the right context.
Change-Id: I32c5ac4b679559886e1efeb4b5483b92dfc94af9
Reviewed-on: https://gem5-review.googlesource.com/12109
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
|