[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]

Files Reference

core File Format for Itanium-based platform


Contains an image of a 32-bit or 64-bit process at the time of an error. This core file format applies to the Itanium-based platform only.


A core file is created in the current directory when certain errors occur. Errors such as memory-address violations, illegal instructions, bus errors, and user-generated quit signals commonly cause a core dump. The core file that is created contains a memory image of the terminated process. A process with a saved user ID that differs from the real user ID does not produce a memory image. The contents of a core dump are organized sequentially in the core file as follows:

Core header Defines basic information about the core dump and contains offsets that locate the remainder of the core dump information
coreld_info structures Defines loader information. This structure is specific to the Itanium-based platform only.
thrdctx64 structures Defines kernel thread state information. Since the faulting thread thrdctx64 structure is directly saved in the core header, additional structures are saved here only for multi-threaded programs.
segregion structures Contains the address, size, and type for shared memory segments of the faulting process
Default user stack Contains a copy of the user stack at the time of the core dump 
Default data area (Optional) Contains the user data section 
vm_infox structures (Optional) Contains offset and size information for memory mapped regions
Memory mapped regions (Optional) Contains the memory mapped regions

The core_dumpxx structure, defined by the core.h file, occurs at the beginning of a core file. The core_dumpxx structure includes the following fields:

Field Type Field Name Description
char c_signo The number of the signal that caused the error
char c_flag A bit field that describes the core dump type. The meanings of the bits are as follows:
    FULL_CORE core contains the data sections (0x01)
    CORE_VERSION_1 core was generated by version 4 or higher of the operating system (0x02)
    MSTS_VALID core contains __context structures (0x04)
    CORE_BIGDATA core contains big data (0x08)
    UBLOCK_VALID core contains the u_block structure (0x10)
    USTACK_VALID core contains the user stack (0x20)
    LE_VALID core contains at least one module (0x40)
    CORE_TRUNC core was truncated (0x80)
ushort c_entries The number of core dump modules
int c_version Core file format version
unsigned long long c_fdsinfox Offset to fd region in file
unsigned long long c_loader Offset to loader region in file
unsigned long long c_lsize Size of the loader region
uint c_n_thr Number of elements in thread table
unsigned long long c_thr Offset to thread context table
unsigned long long c_segs Number of elements in segregion 
unsigned long long c_segregion Offset to start of segregion table
unsigned long long c_stack Offset of user stack in file
unsigned long long c_stackorg Base address of user stack region
unsigned long long c_size Size of user stack region
unsigned long long c_data Offset to user data region
unsigned long long c_dataorg Base address of user data region
unsigned long long c_datasize Size of user data region
unsigned long long c_sdorg Base address of privately loaded region
unsigned long long c_sdsize Size of user privately loaded region
unsigned long long c_vmregions Number of anonymously mapped areas
unsigned long long c_vmm Offset of start of vm_infox table
struct thrdctx c_flt Faulting thread's context and thread data
struct userx c_u Representation of the user struct and process data

The c_flt field in the core dump contains the thrdctx64 structure of the faulting thread. The thrdctx64 structure includes the thread data and registers as they existed at the time of the fault. The format of the thread context structure is defined by thrdctx64 structure (in the core.h header file) as follows:

thrdctx64 thrdentry64
thread data (in procinfo.h header file)
state of registers (this structure is used for both 32-bit and 64-bit processes)

The c_u field follows this information in the core dump. The c_u field contains the userx64 structure including the user structure fields and the process data as they existed at the time of the fault. The format of the process information structure is defined by the userx64 structure (in the core.h header file) as follows:

userx64 procentry64 process data (in procinfo.h header file)

The coreld_info structure and then the thrdctx64 structures of the other threads (if the process is multi-threaded) follow in the core dump.

The core file contains an array of coreld_info structures (defined by the core.h header file). Each entry describes a contiguous virtual address region (in the process that dumped core) at which a module's text or data section was loaded. The array of coreld_info entries starts at offset c_loader in the core file. Array entries continue until an entry with a ldinfo_size field of 0 occurs. There is more data in the core file following the last coreld_info array entry.

Typically, a program may use the following piece of code to gather information about the modules that were loaded in the process at the time it dumped core:

        FILE *corefile;
        struct core_dumpxx cored;
        unsigned long long loffset;/* offset in core file to loader section */
        unsigned long long lsize;  /* size of the loader section            */
        #define MAXBUF  10000
        char buff[MAXBUF];
        struct coreld_info ldinfo, *ldinfop;

        /* Open core file       */
        corefile = fopen("core", "r");

        /* Read core file header */
        fread(&cored, 1, sizeof(struct core_dumpxx), corefile);

        loffset = cored.c_loader;
        lsize   = cored.c_lsize;

        /* Read the loader section into buff */
        fseek(corefile, loffset, 0);
        fread(buff, 1, lsize, corefile);

        /* Walk through the array of coreld_info entries */

        ldinfop = (struct coreld_info *) buff;
        memcpy(&ldinfo, buff, sizeof(struct coreld_info));

        while (ldinfo.ldinfo_size) {

                printf ("ldinfo_vaddr    = %016llx \n", ldinfo.ldinfo_vaddr);

                printf ("ldinfo_size     = %016llx \n", ldinfo.ldinfo_size);

                printf ("core_offset     = %016llx \n", ldinfo.core_offset);

                printf ("ldinfo_flags    = %016llx \n", ldinfo.ldinfo_flags);

                printf ("ldinfo_pathname = %s \n",


                /* Get the next entry in the array */


                memcpy(&ldinfo, ldinfop, sizeof(struct coreld_info));

The segregion structure and then the user-mode stack follow in the core dump.

The segregion structure contains the information about a shared memory region of the faulting process.

segregion addr
segment start address
size of the segment
type of the document

The pi_flags2 field of the procentry64 structure determines if the core file is of a 32-bit process or a 64-bit process.

By default, the user data, anonymously mapped regions, and vm_infox structures are not included in a core dump. This partial core dump includes the current thread stack, the thread thrdctx64 structures, the user structure, and the state of the registers at the time of the fault. A partial core dump contains sufficient information for a stack traceback. The size of a core dump can also be limited by the setrlimit or setrlimit64 subroutine.

To enable a full core dump, set the SA_FULLDUMP flag in the sigaction subroutine for the signal that is to generate a full core dump. If this flag is set when the core is dumped, the user data section, vm_infox, and anonymously mapped region structures are included in the core dump.

Related Information

The param.h file.

The raise subroutine, setrlimit and setrlimit64 subroutines, setuid subroutine, sigaction subroutine.

Chapter 4. Header Files

[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]