The definition of ioctl is not actually variadic, it just doesn't
specify what the type of the pointer is that it takes as its third
argument. The man page says that that's because it predates void *
being valid C.
By passing this address around (even if it's unused), we avoid having
to extract system call arguments further down the call stack.
Change-Id: I62541237baafaec30bbe3df06b3284dd286a4051
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23456
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Having readable constants for these large numbers is good, but they
used incorrect style, were at global scope, and were only used in one
place.
This change centralizes them where they're used, fixes their style, and
rewrites the actual constants in a way that makes it clear what they're
values are.
Change-Id: Ib89c46fce133d4180296d384a61d51d1fe1f8d20
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23455
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
When the new thread context ctc is created, it should have a copy of
all the state in the original tc, including the original PC. This code
used to specially handle the KVM case by explicitly making this new
context return from the system call immediately by jumping right to
RCX which (assuming a particular instruction was used) is where user
mode should resume.
The first problem with this approach as far as I can tell is that the
CPU will still be in CPL0, ie supervisor mode, and will not have been
forced back into CPL3, ie user mode. This may not have any immediately
visible effect, but may down the line.
Second, this seems unnecessary. The non-special case code will advance
the PC beyond the instruction which triggered the system call. Then
once the new thread starts executing again, it will execute sysret and
return to rcx naturally, just like the original thread will.
The only observed difference is that when executing a gem5 instruction,
the IP is set to the currently executing instruction, and so to avoid
the new context from re-executing the system call, the PC needs to be
advanced. When calling in from KVM, the instruction has already been
"completed", and so the IP should *not* be advanced.
Also note that when reading the PCState object in KVM, it doesn't
figure out where the next instruction is and so NPC is just one
ExtMachInst sized blob later on. Advancing the PC will just move to
an address 8 bytes later, which is very unlikely to be what you want.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I0d97f66e64ce39b13d6700dcf3d7da88d6fe0048
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23199
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is aligning the readlink and access syscalls to the open one,
which is not overloading the openFunc, but it is factoring the
implementation into a openImpl, which is used by both open and openat.
This is needed if passing them to std::function, whose constructor is
not able to handle overloaded functions.
Change-Id: I50a8aacdfd675181b6fe9a2696220ee29cc5bc4b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23260
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This converts the syscall implementations to either use the
OS::byteOrder constant or, if that's not available, the system's
getGuestByteOrder() accessor, to determine the byte order, instead of
relying on TheISA to provide the correct accessor.
Change-Id: Idf7b02ee8d73990224ceac9a5efaec91a5ebf79f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22364
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@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 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>
The fstat64 system call does an upcast on entries in the file
descriptor array to check if the file descriptor has a backing
host-filesystem file opened. It does so because it needs to pass
the host fd into the fstat call (since we rely on the host
filesystem to service filesystem system calls).
The upcast was overly specific. This changeset alters the system
call to use the most general base class of the file descriptor
entries that can satisfy the code.
Change-Id: I10daf820257cea4d678ee6917e01e9cc9cd1cf5e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17110
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: 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>
Currently, the open system call implementation in SE mode
treats /sys/ as a special path that is opened using a
special open handler. The ROC runtime, however, reads
several files in /sys/ that are supported via path
redirection. Here we remove /sys/ from the special files
so that the necessary files may be read via path
redirection.
Change-Id: Ifdab38ea1e6cc486ad43aec96b6e032fe63f137d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12127
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change introduces the concept of a faux-filesystem.
The faux-filesystem creates a directory structure in m5out
(or whatever output dir the user specifies) where system calls
may be redirected.
This is useful to avoid non-determinism when reading files
with varying path names (e.g., variations from run-to-run if
the simulation is scheduled on a cluster where paths may change).
Also, this changeset allows circumventing host pseudofiles which
have information specific to the host processor (such as cache
hierarchy or processor information). Bypassing host pseudofiles
can be useful when executing runtimes in the absence of an
operating system kernel since runtimes may try to query standard
files (i.e. /proc or /sys) which are not relevant to an
application executing in syscall emulation mode.
Change-Id: I90821b3b403168b904a662fa98b85def1628621c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12119
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This changeset enables clone to work with X86KvmCPU model, which
will allow running multi-threaded applications at near hardware
speeds. Even though the application is multi-threaded, the KvmCPU
model uses one event queue, therefore, only one hardware thread
will be used, through KVM, to simulate multiple application threads.
Change-Id: I2b2a7b1edb1c56eeb9c4fa0553cd236029cd53f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18268
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch implements FUTEX_WAKE_OP operation in the futex syscall.
Below is its description:
int futex(int *uaddr, int futex_op, int val,
const struct timespec *timeout,
int *uaddr2, int val3);
This operation was added to support some user-space use cases where more
than one futex must be handled at the same time. The most notable
example is the implementation of pthread_cond_signal(3), which requires
operations on two futexes, the one used to implement the mutex and the
one used in the implementation of the wait queue associated with the
condition variable. FUTEX_WAKE_OP allows such cases to be implemented
without leading to high rates of contention and context switching.
Reference: http://man7.org/linux/man-pages/man2/futex.2.html
Change-Id: I215f3c2a7bdc6374e5dfe06ee721c76933a10f2d
Reviewed-on: https://gem5-review.googlesource.com/c/9630
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
This patch supports FUTEX_CMP_REQUEUE operation. Below is its
description from Linux man page:
futex syscall: int futex(int *uaddr, int futex_op, int val,
const struct timespec *timeout,
int *uaddr2, int val3);
This operation first checks whether the location uaddr still contains
the value val3. If not, the operation fails with the error EAGAIN.
Otherwise, the operation wakes up a maximum of val waiters that are
waiting on the futex at uaddr. If there are more than val waiters, then
the remaining waiters are removed from the wait queue of the source
futex at uaddr and added to the wait queue of the target futex at
uaddr2. The val2 argument specifies an upper limit on the number of
waiters that are requeued to the futex at uaddr2.
Reference: http://man7.org/linux/man-pages/man2/futex.2.html
Change-Id: I6d2ebd19a935b656d19d8342f7ab450c0d2031f4
Reviewed-on: https://gem5-review.googlesource.com/c/9629
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
This patch adds support for two operations in futex system call:
FUTEX_WAIT_BITSET and FUTEX_WAKE_BITSET. The two operations are used to
selectively wake up a certain thread waiting on a futex variable.
Basically each thread waiting on a futex variable is associated with a
bitset that is checked when another thread tries to wake up all threads
waiting on the futex variable.
Change-Id: I2300e53b144d8fae226423fa2efb0238c1d93ef9
Reviewed-on: https://gem5-review.googlesource.com/c/9621
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
A recent patch add the use of the macro:
CMSG_ALIGN
This macro is not very cross-platform, and needs to be
defined according to the platform.
This patch defines the missing macro on MacOS.
Change-Id: I582f69e652dc060b4532358141179ad6d37eafc7
Reviewed-on: https://gem5-review.googlesource.com/c/16102
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.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>
