arch/arm64/include/uapi/asm/sigcontext.h
Source file repositories/reference/linux-study-clean/arch/arm64/include/uapi/asm/sigcontext.h
File Facts
- System
- Linux kernel
- Corpus path
arch/arm64/include/uapi/asm/sigcontext.h- Extension
.h- Size
- 11386 bytes
- Lines
- 359
- Domain
- Architecture Layer
- Bucket
- arch/arm64
- Inferred role
- Architecture Layer: implementation source
- Status
- source implementation candidate
Why This File Exists
CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/types.hasm/sve_context.h
Detected Declarations
struct sigcontextstruct _aarch64_ctxstruct fpsimd_contextstruct esr_contextstruct poe_contextstruct extra_contextstruct sve_contextstruct tpidr2_contextstruct fpmr_contextstruct za_contextstruct zt_contextstruct gcs_context
Annotated Snippet
struct sigcontext {
__u64 fault_address;
/* AArch64 registers */
__u64 regs[31];
__u64 sp;
__u64 pc;
__u64 pstate;
/* 4K reserved for FP/SIMD state and future expansion */
__u8 __reserved[4096] __attribute__((__aligned__(16)));
};
/*
* Allocation of __reserved[]:
* (Note: records do not necessarily occur in the order shown here.)
*
* size description
*
* 0x210 fpsimd_context
* 0x10 esr_context
* 0x8a0 sve_context (vl <= 64) (optional)
* 0x20 extra_context (optional)
* 0x10 terminator (null _aarch64_ctx)
*
* 0x510 (reserved for future allocation)
*
* New records that can exceed this space need to be opt-in for userspace, so
* that an expanded signal frame is not generated unexpectedly. The mechanism
* for opting in will depend on the extension that generates each new record.
* The above table documents the maximum set and sizes of records than can be
* generated when userspace does not opt in for any such extension.
*/
/*
* Header to be used at the beginning of structures extending the user
* context. Such structures must be placed after the rt_sigframe on the stack
* and be 16-byte aligned. The last structure must be a dummy one with the
* magic and size set to 0.
*
* Note that the values allocated for use as magic should be chosen to
* be meaningful in ASCII to aid manual parsing, ZA doesn't follow this
* convention due to oversight but it should be observed for future additions.
*/
struct _aarch64_ctx {
__u32 magic;
__u32 size;
};
#define FPSIMD_MAGIC 0x46508001
struct fpsimd_context {
struct _aarch64_ctx head;
__u32 fpsr;
__u32 fpcr;
__uint128_t vregs[32];
};
/*
* Note: similarly to all other integer fields, each V-register is stored in an
* endianness-dependent format, with the byte at offset i from the start of the
* in-memory representation of the register value containing
*
* bits [(7 + 8 * i) : (8 * i)] of the register on little-endian hosts; or
* bits [(127 - 8 * i) : (120 - 8 * i)] on big-endian hosts.
*/
/* ESR_EL1 context */
#define ESR_MAGIC 0x45535201
struct esr_context {
struct _aarch64_ctx head;
__u64 esr;
};
#define POE_MAGIC 0x504f4530
struct poe_context {
struct _aarch64_ctx head;
__u64 por_el0;
};
/*
* extra_context: describes extra space in the signal frame for
* additional structures that don't fit in sigcontext.__reserved[].
*
* Note:
*
* 1) fpsimd_context, esr_context and extra_context must be placed in
* sigcontext.__reserved[] if present. They cannot be placed in the
* extra space. Any other record can be placed either in the extra
* space or in sigcontext.__reserved[], unless otherwise specified in
Annotation
- Immediate include surface: `linux/types.h`, `asm/sve_context.h`.
- Detected declarations: `struct sigcontext`, `struct _aarch64_ctx`, `struct fpsimd_context`, `struct esr_context`, `struct poe_context`, `struct extra_context`, `struct sve_context`, `struct tpidr2_context`, `struct fpmr_context`, `struct za_context`.
- Atlas domain: Architecture Layer / arch/arm64.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.