OpenSolaris

Printable Version Enter a New Search
Bug ID 6491365
Synopsis x86 CR registers should be saved in user and kernel core dumps and be readable by debuggers
State 10-Fix Delivered (Fix available in build)
Category:Subcategory kernel:procfs
Keywords
Responsible Engineer Krishnendu Sadhukhan
Reported Against
Duplicate Of
Introduced In solaris_nevada
Commit to Fix snv_101
Fixed In snv_101
Release Fixed solaris_nevada(snv_101)
Related Bugs 6335094 , 6440621 , 6724774
Submit Date 8-November-2006
Last Update Date 22-October-2008
Description
The x86 CR registers CR0, CR2, CR3 and CR4 should be saved at the time of a fault
for 32-bit systems.

In addition, CR8 should be saved on a core dump on amd64 systems.

These registers should be output to user and kernel core files, and should be
visible in mdb.

Common example:
A user program dies due to a page fault, generates a SIGSEGV, and leaves a core file.

If the faulting instruction was a memory reference off a segment register, there is
no way to determine the faulting address because CR2 is not saved to the core file,
the faulting instruction may show only a reference off a segment register, and only
segment register selectors are saved.

Debugging such a reference as part of a panic is a little easier, but the additional
processor state in the other CR registers may still be helpful.
The information about the actual fault is stored in the pr_info.si_addr field of the lwpstatus info, stored in the core file:

% elfdump -n core
...
  entry [11]
    namesz: 0x5
    descsz: 0x320
    type:   [ NT_LWPSTATUS ]
    name:
        CORE\0
    desc: (lwpstatus_t)
        pr_flags:       [ PR_PCINVAL PR_MSACCT PR_MSFORK ]
        pr_lwpid:       1
        pr_why:         0x0
        pr_what:        0x0
        pr_cursig:      [ SIGSEGV ]
        pr_info:
            si_signo:   [ SIGSEGV ]
            si_errno:   0
            si_code:    [ SEGV_MAPERR ]
            si_addr:    0xefd61af0
        pr_lwppend:     0
...

(see the si_addr field)

So there is no need to add anything to the core dump to get this information.  It would be reasonable to request that mdb be
able to print this information.
Work Around
N/A
Comments
N/A