|
|
A process with an effective user (group) ID different from the real user (group) ID will not produce a core image. If a file named core already exists in the process' working directory and is not a regular file or has links, no core image is produced.
The core image contains all mutable portions of the process' virtual address space plus information from the system about the state of the process. If the text segment is read-only and shared, or separated from data space, it is not dumped. Attached shared memory, shared data, and shared library data are dumped.
The core file is logically divided into a series of sections. A section either describes the core file, contains a copy of the contents of a kernel data structure, or contains a copy of the contents of the process' memory at the time of the dump.
Each section consists of a header describing the section,
optional additional information about the section's contents,
and the section's contents.
Consecutive sections may not be physically adjacent.
Whilst any optional information physically follows the header,
the contents may not.
The header contains the size and offset of its contents.
The headers themselves form a chain.
The section header is defined in <sys/paccess.h>:
struct coresecthead {
uchar_t cs_stype; /* Type of section (CORES_xxx) */
uchar_t cs_hsize; /* Size (bytes) of section header */
ushort cs_osize; /* Size (bytes) of optional info */
union {
struct {
short csxp_rflg; /* Associated pregion's p_flags */
short csxp_rtyp; /* Associated pregion's p_type */
} csx_preg;
ulong_t csx_magic; /* COREMAGIC_xxx for MAGIC, OFFSETS */
} cs_x;
ulong_t cs_vaddr; /* Virtual address of contents */
ulong_t cs_vsize; /* Size (bytes) of contents */
long cs_sseek; /* Offset of this section's contents */
long cs_hseek; /* Offset of next section's header */
};
Each coresecthead structure
in a core file contains:
Should a future release or update of the system require an expanded coresecthead structure, the additional fields will be added at the end of the structure. Programs should therefore not assume that sizeof(struct coresecthead) bytes were written to the core file; the cs_hsize field contains the number of bytes that were written.
The defined cs_stype section types include:
The last longword of the coreoffsets structure is always the size of that structure itself (including that last longword):
struct coreoffsets {
uoff u_info; /* interface version (C_VERSION) */
uoff u_user; /* offset of upage in core file */
uoff u_ldt; /* offset of ldt in core file */
uoff u_data; /* offset of data in core file */
uoff u_stack; /* offset of stack in core file */
uoff u_usize; /* size of uarea */
uoff u_uaddr; /* kernel virtual address of uarea */
uoff u_ar0; /* user register save area pointer */
uoff u_fps; /* floating point save area */
uoff u_fper; /* 2.3 field */
uoff u_fpemul; /* separate emulator save area */
uoff u_fpvalid; /* valid save fpstate */
uoff u_weitek; /* flag indicating weitek usage */
uoff u_weitek_reg; /* weitek save area */
uoff u_ssize; /* stack size */
uoff u_dsize; /* data size */
uoff u_tsize; /* text size */
uoff u_comm; /* name of executable */
uoff u_ldtlimit; /* size of ldt */
uoff u_sub; /* stack upper bound */
uoff u_sdata; /* 3.2 u_exdata.ux_datorg */
uoff u_mag; /* u_exdata.ux_mag */
uoff u_sigreturn;
uoff u_signal;
uoff uvstack; /* virtual address of stack top */
uoff uvtext; /* virtual address of text */
uoff size; /* size of this structure */
};
Some of these fields contain information about the
core file's layout:
The other fields in the coreoffsets structure are the offset (in bytes) from the beginning of the USERS_UAREA contents of the similarly-named fields in the dumped user structure:
| Structure | ||
|---|---|---|
| coreoffsets field | user offset | Comments |
| u_ar0 | u_ar0 | Kernel virtual address of process' registers |
| u_fps | u_fps | Saved FPU hardware state |
| u_fpemul | u_fps | Saved FPU emulator state |
| u_fpvalid | u_fpvalid | FPU state saved? |
| u_weitek | u_weitek | |
| u_weitek_reg | u_weitek_reg | |
| u_ssize | u_ssize | Pages of process' stack in core |
| u_dsize | u_dsize | Pages of process' data in core |
| u_tsize | u_tsize | Pages of process' separate/shared text |
| u_comm | u_comm | Executable file's basename |
| u_ldtlimit | u_ldtlimit | |
| u_sub | u_sub | Lowest address in process' stack |
| u_sdata | u_exdata.ux_datorg | Process' data virtual address |
| u_mag | u_exdata.ux_mag | Executable's magic number |
| u_sigreturn | u_sigreturn | |
| u_signal | u_signal[0] | |
The size of the core file never exceeds the process' ulimit(S) in effect at the time of the core dump. If the ulimit is insufficient to contain the entire user and coreoffsets structures plus their corresponding coresecthead headers, nothing is written to the core file. If the ulimit is too small to contain both the process' stack (PT_STACK) and data (PT_DATA) memory, only the stack is written (plus the user and coreoffsets structures); if the ulimit is too small to contain the stack, then only the user and coreoffsets sections are written. Other sections are squeezed in as the ulimit permits.
Version 1 core files contain only the first two pages of the user structure (always at offset zero), the process' stack and data memory, and the coreoffsets structure (always at the end of the core file). No other memory or information are present, and no coresecthead structures are dumped. In particular, there is no CORES_MAGIC section in a genuine version 1 core file.
The u_ldt field of the coreoffsets structure in a genuine version 1 core file may point to memory which was not actually dumped, or which was only partially dumped.
The version 2 core file format is designed so most programs expecting a version 1 core file should continue to work unchanged, although they will not be able to access the additional information present in version 2 files. However, some utilities require version 1 core files. The corex(C) command converts a version 2 core file into its version 1 equivalent. The LDT in the converted core file may -- like genuine version 1 core files -- either not be dumped or be only partially dumped.
The CORES_MAGIC section actually overlays the beginning of the CORES_UAREA section's contents so that, like version 1 core files, the user structure in version 2 core files starts at offset zero. There is no data of consequence in the overlaid bytes, being the furthermost extent of the kernel's stack.
The u_comm string in the user structure is not necessarily null-terminated.
The u_ar0 field in the coreoffsets structure is the offset in the CORES_UAREA section of the kernel's virtual address which in turn points to the process' registers. That offset is not the offset of the saved registers themselves. The dumped u_ar0 kernel virtual address refers to core dumped someplace in the CORES_UAREA section; the pointed to dumped core is arranged as described in <sys/regs.h>.