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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
