GETCONTEXT(2) System Calls GETCONTEXT(2)
NAME
getcontext,
getcontext_extd,
setcontext - get and set current user
context
SYNOPSIS
#include <ucontext.h> int getcontext(
ucontext_t *ucp);
int getcontext_extd(
ucontext_t *ucp,
uint32_t flags);
int setcontext(
const ucontext_t *ucp);
DESCRIPTION
The
getcontext() function initializes the structure pointed to by
ucp to the current user context of the calling process. The
ucontext_t type that
ucp points to defines the user context and includes the
contents of the calling process' machine registers, the signal mask,
and the current execution stack.
The
ucontext_t structure is a part of the system ABI. However, most
architectures have added additional register states such as the
extended vector and floating point registers that are not part of that.
To facilitate getting that state (such as the x86 xsave area) the
getcontext_extd() function exists. Once called, the context will be
initialized and is suitable for use in other context operations just as
though one had called
getcontext().
When calling the
getcontext() function the
ucontext_t is completely
overwritten without regards for what is currently present. This is
different when using
getcontext_extd(). Instead, the
ucontext_t structure is read by the kernel and it assumes that the user has
initialized it. This allows the system to consider members of the
ucontext_T (such as the
uc_xsave member on x86) to point to properly
sized memory.
To allow for all extended states to be copied out,
ucp must be
allocated with
ucontext_alloc(3C). Otherwise whether it is declared on
the stack, as global data, allocated dynamically, or part of a
structure,
ucp must be zeroed through a call to
bzero(3C) or
memset(3C) prior to calling
getcontext_extd(). Improper initialization can lead
to memory safety bugs, making it critical that this is done.
The
flags member must be zero and is present to allow for what is
copied out to change in the future. This indicates that the system
should attempt to copy out all extended states, though if the
ucontext_t was not allocated with
ucontext_alloc(3C), some extended
states may not be. This happens because
ucontext_alloc(3C) takes care
of allocating and setting up the
ucontext_t to indicate that memory
beyond the
ucontext_t is valid and the corresponding flags in the
structure are set.
The
setcontext() function restores the user context pointed to by
ucp.
A successful call to
setcontext() does not return; program execution
resumes at the point specified by the
ucp argument passed to
setcontext(). The
ucp argument should be created either by a prior
call to
getcontext(), or by being passed as an argument to a signal
handler. If the
ucp argument was created with
getcontext(), program
execution continues as if the corresponding call of
getcontext() had
just returned. If the
ucp argument was created with
makecontext(3C),
program execution continues with the function passed to
makecontext(3C). When that function returns, the process continues as
if after a call to
setcontext() with the
ucp argument that was input to
makecontext(3C). If the
ucp argument was passed to a signal handler,
program execution continues with the program instruction following the
instruction interrupted by the signal. If the
uc_link member of the
ucontext_t structure pointed to by the
ucp argument is NULL, then this
context is the main context, and the process will exit when this
context returns. The effects of passing a
ucp argument obtained from
any other source are unspecified.
RETURN VALUES
On successful completion,
setcontext() does not return and
getcontext()
and
getcontext_extd() returns 0. Otherwise, -1 is returned.
ERRORS
No errors are defined for
getcontext() or
setcontext().
The
getcontext_extd() function only sets
errno in some circumstances
when it fails. The function may fail if:
EINVAL
flags had invalid values.
USAGE
When a signal handler is executed, the current user context is saved
and a new context is created. If the thread leaves the signal handler
via
longjmp(3C), then it is unspecified whether the context at the time
of the corresponding
setjmp(3C) call is restored and thus whether
future calls to
getcontext() will provide an accurate representation of
the current context, since the context restored by
longjmp(3C) may not
contain all the information that
setcontext() requires. Signal
handlers should use
siglongjmp(3C) instead.
Portable applications should not modify or access the
uc_mcontext member of
ucontext_t. A portable application cannot assume that
context includes any process-wide static data, possibly including
errno. Users manipulating contexts should take care to handle these
explicitly when required.
INTERFACE STABILITY
CommittedSEE ALSO
sigaction(2),
sigaltstack(2),
sigprocmask(2),
bsd_signal(3C),
makecontext(3C),
setjmp(3C),
sigsetjmp(3C),
ucontext_alloc(3C),
ucontext.h(3HEAD),
attributes(7),
standards(7)illumos January 24, 2023 illumos