The create() method on Params structs usually instantiate SimObjects
using a constructor which takes the Params struct as a parameter
somehow. There has been a lot of needless variation in how that was
done, making it annoying to pass Params down to base classes. Some of
the different forms were:
const Params &
Params &
Params *
const Params *
Params const*
This change goes through and fixes up every constructor and every
create() method to use the const Params & form. We use a reference
because the Params struct should never be null. We use const because
neither the create method nor the consuming object should modify the
record of the parameters as they came in from the config. That would
make consuming them not idempotent, and make it impossible to tell what
the actual simulation configuration was since it would change from any
user visible form (config script, config.ini, dot pdf output).
Change-Id: I77453cba52fdcfd5f4eec92dfb0bddb5a9945f31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35938
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The System class has a few different arrays of values which each
correspond to a thread of execution based on their position. This
change collects them together into a single class to make managing them
easier and less error prone. It also collects methods for manipulating
those threads as an API for that class.
This class acts as a collection point for thread based state which the
System class can look into to get at all its state. It also acts as an
interface for interacting with threads for other classes. This forces
external consumers to use the API instead of accessing the individual
arrays which improves consistency.
Change-Id: Idc4575c5a0b56fe75f5c497809ad91c22bfe26cc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25144
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The components in base/loader were moved into a namespace called
Loader. This will make it easier to add loader components with fairly
short natural names which don't invite name collisions.
gem5 should use namespaces more in general for that reason and to make
it easier to write independent components without having to worry about
name collisions being added in the future.
Unfortunately this namespace has the same name as a class used to load
an object file into a process object. These names can be disambiguated
because the Process loader is inside the Process scope and the Loader
namespace is at global scope, but it's still confusing to read.
Fortunately, this shouldn't last for very long since the responsibility
for loading Processes is going to move to a fake OS object which will
expect to load a particular type of Process, for instance, fake 64 bit
x86 linux will load either 32 or 64 bit x86 processes.
That means that the capability to feed any binary that matches the
current build into gem5 and have gem5 figure out what to do with it
will likely be going away in the future. That's likely for the best,
since it will force users to be more explicit about what they're trying
to do, ie what OS they want to try to load a given binary, and also
will prevent loading two or more Processes which are for different OSes
to the same system, something that's possible today as far as I know
since there are no consistency checks.
Change-Id: Iea0012e98f39f5e20a7c351b78cdff9401f5e326
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24783
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The GuestABI used to call the system-calls infers the size of values
read from the registers based on the function signature of the system
call. For mmap this was causing offset to be truncated to a 32-bit
value. In the GPUComputeDriver mmap, the offset must be a 64-bit
value. This fixes a bug where the doorbell memory was not setup and
causing GPU applications to fail.
Change-Id: I75d9b32c0470d1907c68826ef81cf6cd46f60ea7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27367
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
When handling a system call, external code would call Process::syscall
which would extract the syscall number, that would call the base
class' doSyscall method, that would call into the subclass' getDesc
to get the appropriate descriptor, and then doSyscall would check
that a syscall was found and call into it.
Instead, we can just make the SyscallDescTable optionally check for
missing syscalls (in case we want to check multiple tables), and
make syscall look up the appropriate descriptor and call it. The base
implementation of syscall would then do the only bit of doSyscall that
is no longer being handled, incrementing the numSyscalls stat.
Change-Id: If102c156830ed2997d177dc6937cc85dddadf3f9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24119
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Also add the syscall number into the SyscallDesc class.
The common table structure is basically just a map that extracts its
key value from the SyscallDesc class using a new num() accessor. By
using a map instead of an array (like RISCV was already doing), it's
easy to support gaps of arbitrary size and non-zero offsets of groups
of system calls without lots of filler or additional logic. This
simplified the ARM system call tables in particular which had a lot
of filler entries.
Also, both the 32 and 64 bit ARM syscall tables had entries for a
syscall at 123456 which was the "Angel SWI system call". This value
is actually the immediate constant passed to the SWI system call
instruction and is not interpreted as the system call number in linux.
This constant can be intercepted by hardware or a simulator to, for
instance, implement ARM semihosting.
Also, that constant in combination with the SWI instruction is only
used for semihosting in 32 bit ARM mode, not in 64 bit mode or in
thumb.
Since checking for that system call number was very likely a mistake
from misinterpreting how the semihosting calls work, this change
drops those checks.
Change-Id: I9b2a902d7326791449cf0e1b98e932dcadba54f7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24117
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This function is no longer used anywhere in gem5.
Small helper functions which had been put alongside vtophys on ARM and
RISCV were also moved into src/arch/arm/remote_gdb.cc and
src/arch/power/pagetable.hh, the only places they were used.
Change-Id: Iba72f6c4b797a35a785a5bb781d602c943541fa7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26234
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
My new computer has a dynamic linker which seems to use the pread64
system call, and since that gets pulled in when running tests, that
needs to be implemented for tests to pass on that machine, making it
possible to detect problems the failure might ohterwise mask.
This is only really necessary for 64 bit linux, but while I'm here I
hooked it up for 32 bit linux as well. I also added pwrite64 for 32 bit
linux since that was only enabled for 64 bit.
Change-Id: I8d2061d30e98a1581c5e30b522b6ba12aea20ecd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26604
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
These ABIs (one 32 bit and one 64 bit) take advantage of the
GenericSyscallABI and X86Linux::SyscallABI partial ABIs set up earlier.
This removes x86's dependence on the getSyscallArg and setSyscallReturn
Process methods.
Change-Id: Ia07834cea1afa827d77e590af5397e2a1e0e2099
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23443
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Information about what kernel to load and how to load it was built
into the System object and its subclasses. That overloaded the System
object and made it responsible for too many things, and also was
somewhat awkward when working with SE mode which doesn't have a kernel.
This change extracts the kernel and information related to it from the
System object and puts into into a OsKernel or Workload object.
Currently the idea of a "Workload" to run and a kernel are a bit
muddled, an unfortunate carry-over from the original code. It's also an
implication of trying not to make too sweeping of a change, and to
minimize the number of times configs need to change, ie avoiding
creating a "kernel" parameter which would shortly thereafter be
renamed to "workload".
In future changes, the ideas of a kernel and a workload will be
disentangled, and workloads will be expanded to include emulated
operating systems which shephard and contain Process-es for syscall
emulation.
This change was originally split into pieces to make reviewing it
easier. Those reviews are here:
https: //gem5-review.googlesource.com/c/public/gem5/+/22243
https: //gem5-review.googlesource.com/c/public/gem5/+/24144
https: //gem5-review.googlesource.com/c/public/gem5/+/24145
https: //gem5-review.googlesource.com/c/public/gem5/+/24146
https: //gem5-review.googlesource.com/c/public/gem5/+/24147
https: //gem5-review.googlesource.com/c/public/gem5/+/24286
Change-Id: Ia3d863db276a023b6a2c7ee7a656d8142ff75589
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26466
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
By using braced initializer lists and dropping the default
unimplementedFunc implementation function, the SyscallDesc tables
become a lot less crowded, and it's now very obvious which syscalls
are implemented just by quickly visually scanning the table.
This will also make it a lot easier to change the underlying type
stored in the table without having to adjust all of the instances
within them.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I7821de74812e1c02ca4550fc9c46cc2188cf1bd0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23189
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@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>
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>
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>
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>
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>
Some parts of clone are architecture dependent. In some cases, we are
able to use architecture-specific helper functions or register
aliases. However, there is still some architecture-specific that is
protected by ifdefs in the common clone implementation.
Move these architecture-specific bits to the architecture-specific OS
class instead to avoid these ifdefs and make the code a bit more
readable.
Change-Id: Ia0903d738d0ba890863bddfa77e3b717db7f45de
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Cc: Giacomo Travaglini <giacomo.travaglini@arm.com>
Cc: Javier Setoain <javier.setoain@arm.com>
Cc: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15435
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Change a66d12c guards the selection of getdents()
in x86's process.cc file with SYS_getdents, however
process.cc does not include the right header for
SYS_getdents, which leads to x86 choosing the
unimplemented call. This change adds sys/syscall.h to
address the problem.
This change also adds sys/syscall.hh to syscall_emu.cc,
which only includes syscall.hh and may not be supported on
all systems.
Change-Id: If1adcf41e9e455de5f2827ba98c542fdcacdc22e
Reviewed-on: https://gem5-review.googlesource.com/c/14775
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
The implementation of the getdents syscall relies on SYS_getdents, which
is not available on all archs, because the getdents syscall has been
superseded by getdents64, and does not exist on newer archs such as
aarch64.
This leads the build to break on aarch64 hosts with error:
error: 'SYS_getdents' was not declared in this scope
Change-Id: I8701fb5b61c0418b14a9463ef135a391a7f7a9ba
Reviewed-on: https://gem5-review.googlesource.com/c/14596
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
