[Crash-utility] Heads up re: the 2.6.25 x86/x86_64 merge

Dave Anderson anderson at redhat.com
Tue Feb 19 19:52:56 UTC 2008


This is likely going to be a painful process getting crash to
work right with these kernels again...

The tss_struct hack I suggested to Solofo earlier will actually get
an x86_64 session started:

--- crash-4.0-4.13/x86_64.c.orig
+++ crash-4.0-4.13/x86_64.c
@@ -255,7 +255,7 @@ x86_64_init(int when)
                 MEMBER_OFFSET_INIT(thread_struct_rsp, "thread_struct", "rsp");
                 MEMBER_OFFSET_INIT(thread_struct_rsp0, "thread_struct", "rsp0");
                 STRUCT_SIZE_INIT(tss_struct, "tss_struct");
-               MEMBER_OFFSET_INIT(tss_struct_ist, "tss_struct", "ist");
+               MEMBER_OFFSET_INIT(tss_struct_ist, "x86_hw_tss", "ist");
                 MEMBER_OFFSET_INIT(user_regs_struct_rip,
                         "user_regs_struct", "rip");
                 MEMBER_OFFSET_INIT(user_regs_struct_rsp,

but there will be numerous obstacles to overcome due to other structure
related changes.  Fundamental data structures that are crucial to crash
have changed.  Many are just name changes, but will cause "invalid structure
member offset" failures like so:

   crash> bt 1

   bt: invalid structure member offset: thread_struct_rsp
       FILE: x86_64.c  LINE: 3645  FUNCTION: x86_64_get_sp()

   [./crash] error trace: 514b52 => 4d2ce8 => 4d3c3e => 4fff86
   PID: 1      TASK: ffff81012fa9e7e0  CPU: 1   COMMAND: "init"

     4fff86: OFFSET_verify+159
     4d3c3e: x86_64_get_sp+110
     4d2ce8: x86_64_get_stack_frame+107
     514b52: get_netdump_regs_x86_64+798

   WARNING: Because this kernel was compiled with gcc version 4.2.3, certain
            commands or command options may fail unless crash is invoked with
            the  "--readnow" command line option.

   bt: invalid structure member offset: thread_struct_rsp
       FILE: x86_64.c  LINE: 3645  FUNCTION: x86_64_get_sp()

   crash>


which happens because the x86_64 thread_struct.rsp member has been
renamed thread_struct.sp.  Another example is the venerable pt_regs
structure, which has changed many of its member names, from:

struct pt_regs {
     long unsigned int r15;
     long unsigned int r14;
     long unsigned int r13;
     long unsigned int r12;
     long unsigned int rbp;
     long unsigned int rbx;
     long unsigned int r11;
     long unsigned int r10;
     long unsigned int r9;
     long unsigned int r8;
     long unsigned int rax;
     long unsigned int rcx;
     long unsigned int rdx;
     long unsigned int rsi;
     long unsigned int rdi;
     long unsigned int orig_rax;
     long unsigned int rip;
     long unsigned int cs;
     long unsigned int eflags;
     long unsigned int rsp;
     long unsigned int ss;
}

to:

struct pt_regs {
     long unsigned int r15;
     long unsigned int r14;
     long unsigned int r13;
     long unsigned int r12;
     long unsigned int bp;
     long unsigned int bx;
     long unsigned int r11;
     long unsigned int r10;
     long unsigned int r9;
     long unsigned int r8;
     long unsigned int ax;
     long unsigned int cx;
     long unsigned int dx;
     long unsigned int si;
     long unsigned int di;
     long unsigned int orig_ax;
     long unsigned int ip;
     long unsigned int cs;
     long unsigned int flags;
     long unsigned int sp;
     long unsigned int ss;
}

Anyway, the same types of issues will plague x86 as well.

What a pain in the ass...

BTW, if anybody happens to have an x86 vmlinux/vmcore pair
from a 2.6.25 kernel that they could make available to me,
I'd appreciate it.

Many thanks to Solofo for making the x86_64 dumpfile available
to work with.

Back to the drawing board...
   Dave




More information about the Crash-utility mailing list