RE: [Crash-utility] crash version 4.0-3.18 is available
by Castor Fu
Xavier:
I suspect that if rpc_execute is duplicated, there are other duplicated
symbols
and so we matched some other symbol, got another offset, and at that
point we're headed down the wrong path. It hadn't occurred to me that
there could be conflicts, but in retrospect it makes sense.
Not quite sure how to resolve this. I'd hate to trust that we could
reliably
duplicate Linux'es module loading algorithm.
________________________________
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of xb
Sent: Friday, February 02, 2007 1:32 AM
To: anderson(a)redhat.com
Cc: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] crash version 4.0-3.18 is available
Hi Dave and all
I still have some problems with module symbols on ia64. (I built crash
4.0-3.17 + 4.0-3.17-to-4.0-3.18.patch).
It seems that when I run the commans:
mod -s <module name>
the text symbol addresses are not the ones provided by kallsyms.
Any idea ?
Thanks in advance.
Xavier
Traces
------------------------------------------------------------------------
-------------------------------------------------------------
# ./crash /boot/vmlinux-2.6.18-B64k.1.7
crash 4.0-3.17
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Red Hat, Inc.
...
GNU gdb 6.1
...
This GDB was configured as "ia64-unknown-linux-gnu"...
KERNEL: /boot/vmlinux-2.6.18-B64k.1.7
DUMPFILE: /dev/mem
CPUS: 8
DATE: Fri Feb 2 10:25:27 2007
UPTIME: 13 days, 16:26:51
LOAD AVERAGE: 0.75, 0.66, 0.58
TASKS: 286
NODENAME: xxx
RELEASE: 2.6.18-B64k.1.7
VERSION: #1 SMP Fri Jan 5 14:05:06 CET 2007
MACHINE: ia64 (1599 Mhz)
MEMORY: 63.9 GB
PID: 17276
COMMAND: "crash"
TASK: e000002025600000 [THREAD_INFO: e000002025600f40]
CPU: 7
STATE: TASK_RUNNING (ACTIVE)
crash> sym -l |grep rpc_execute
a000000207d34a80 (t) __rpc_execute
a000000207d351e0 (t) rpc_execute
a000000207d5a590 (?) rpc_execute
a000000207d5bde0 (r) __ksymtab_rpc_execute
a000000207d5c6d0 (r) __kstrtab_rpc_execute
a000000207d5cab0 (r) __kcrctab_rpc_execute
crash> disas rpc_execute
No symbol "rpc_execute" in current context.
crash> mod -s sunrpc
MODULE NAME SIZE OBJECT FILE
a000000207d82280 sunrpc 414976
/lib/modules/2.6.18-B64k.1.7/kernel/net/sunrpc/sunrpc.ko
crash> disas rpc_execute
Dump of assembler code for function rpc_execute:
0xa000000207d5ac10 <rpc_execute+0>: [MII] break.m 0x0
0xa000000207d5ac11 <rpc_execute+1>: break.i 0x0
0xa000000207d5ac12 <rpc_execute+2>: break.i 0x0
...
End of assembler dump.
crash> disas 0xa000000207d351e0 0xa000000207d35200
# This one is OK
Dump of assembler code from 0xa000000207d351e0 to 0xa000000207d35200:
0xa000000207d351e0: [MMI] nop.m 0x0;;
0xa000000207d351e1: alloc r34=ar.pfs,5,4,0
0xa000000207d351e2: mov r33=b0
0xa000000207d351f0: [MMI] nop.m 0x0
0xa000000207d351f1: mov r35=r1
0xa000000207d351f2: adds r17=208,r32;;
End of assembler dump.
crash>
Dave Anderson wrote:
- Enhancement to the "mod" command to expand the number of
section
arguments to the internal "add-symbol-file" command issued to
gdb to
load the debug data for module objects. On most
architectures, this
allows the usage of the command construct "p
[module-symbol-name]" to
print out the module data structure in the same way that is
done for
kernel proper data structure names. (castor.fu(a)3pardata.com)
- Two enhancements to significantly speed up the initialization
of
crash sessions when running against multi-gigabyte xen kernels
or
xendumps. The cache of mfn-to-phys_to_machine_mapping page
has been
changed from a single-mfn-to-phys_to_machine_mapping page
format to
storing a contiguous-range-of-mfns-to-phys_to_machine_mapping
format.
This benefit is primarily seen during the "gathering module
symbol
data" phase. The second change simply increases the size of
the
pfn-to-xendump-page-offset cache. (anderson(a)redhat.com)
- Fix for a segmentation violation during the "gathering task
table
data" phase of initialization if the thread_info structure of
the
runqueue-advertised active task has been freed. This has only
ever
been seen in a xendump created by "xm dump-core -L
[guest-domain]".
(anderson(a)redhat.com)
- Cosmetic fix to prepend newlines to messages that happen to be
generated during any of the "please wait" segments of
initialization.
(anderson(a)redhat.com)
- Addressed several compiler warnings when using
-D_FORTIFY_SOURCE=2.
Some are in gdb code that is never exercised, others were
legitimate
but would require impossible code paths, but one of them could
result in runaway "help -t" output if the kernel was built
without
IKCONFIG. (bwalle(a)suse.de)
- Fix for the s390x "bt -f" command option, which was displaying
the
stack as a sequence of 32-bit words which were dumped
"backwards",
i.e., at the wrong offset. (krader(a)us.ibm.com)
- http://people.redhat.com/anderson/4.0-3.17-to-4.0-3.18.patch
Download from: http://people.redhat.com/anderson
________________________________
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
17 years, 10 months
- 1
- 0
crash version 4.0-3.18 is available
by Dave Anderson
- Enhancement to the "mod" command to expand the number of section
arguments to the internal "add-symbol-file" command issued to gdb to
load the debug data for module objects. On most architectures, this
allows the usage of the command construct "p [module-symbol-name]" to
print out the module data structure in the same way that is done for
kernel proper data structure names. (castor.fu(a)3pardata.com)
- Two enhancements to significantly speed up the initialization of
crash sessions when running against multi-gigabyte xen kernels or
xendumps. The cache of mfn-to-phys_to_machine_mapping page has been
changed from a single-mfn-to-phys_to_machine_mapping page format to
storing a contiguous-range-of-mfns-to-phys_to_machine_mapping format.
This benefit is primarily seen during the "gathering module symbol
data" phase. The second change simply increases the size of the
pfn-to-xendump-page-offset cache. (anderson(a)redhat.com)
- Fix for a segmentation violation during the "gathering task table
data" phase of initialization if the thread_info structure of the
runqueue-advertised active task has been freed. This has only ever
been seen in a xendump created by "xm dump-core -L [guest-domain]".
(anderson(a)redhat.com)
- Cosmetic fix to prepend newlines to messages that happen to be
generated during any of the "please wait" segments of initialization.
(anderson(a)redhat.com)
- Addressed several compiler warnings when using -D_FORTIFY_SOURCE=2.
Some are in gdb code that is never exercised, others were legitimate
but would require impossible code paths, but one of them could
result in runaway "help -t" output if the kernel was built without
IKCONFIG. (bwalle(a)suse.de)
- Fix for the s390x "bt -f" command option, which was displaying the
stack as a sequence of 32-bit words which were dumped "backwards",
i.e., at the wrong offset. (krader(a)us.ibm.com)
- http://people.redhat.com/anderson/4.0-3.17-to-4.0-3.18.patch
Download from: http://people.redhat.com/anderson
17 years, 10 months
- 2
- 3
Fwd: [PATCH] fix s390x stack dump
by Dave Anderson
Subject: [PATCH] fix s390x stack dump
Date: Wed, 31 Jan 2007 14:51:55 -0800
From: "Kurtis D. Rader" <krader(a)us.ibm.com>
To: crash-utility(a)redhat.com
The s390x_back_trace_cmd() function treats the stack as a sequence of
32-bit words. That's obviously wrong and causes confusion because the
two halves of the 64-bit word gets dumped "backwards"; that is, at the
wrong offset. This patch fixes that. I created it against crash 4.0-3.9 but
it applies cleanly to 4.0-3.17.
diff -U3 -p --recursive crash-4.0-3.9/s390x.c crash-4.0-3.9.fixed/s390x.c
--- crash-4.0-3.9/s390x.c 2006-11-02 10:26:50.000000000 -0800
+++ crash-4.0-3.9.fixed/s390x.c 2006-11-02 18:50:57.000000000 -0800
@@ -730,9 +730,9 @@ s390x_back_trace_cmd(struct bt_info *bt)
backchain = ULONG(&stack[backchain - stack_base + bc_offset]);
/* print stack content if -f is specified */
- if((bt->flags & BT_FULL) && !BT_REFERENCE_CHECK(bt)){
+ if ((bt->flags & BT_FULL) && !BT_REFERENCE_CHECK(bt)) {
int frame_size;
- if(backchain == 0){
+ if (backchain == 0) {
frame_size = stack_base - old_backchain
+ KERNEL_STACK_SIZE;
} else {
@@ -740,14 +740,15 @@ s390x_back_trace_cmd(struct bt_info *bt)
(stack_base - old_backchain +
KERNEL_STACK_SIZE));
}
- for(j=0; j< frame_size; j+=4){
+ for (j = 0; j < frame_size; j += 8) {
if(j % 16 == 0){
- fprintf(fp,"\n%08lx: ",old_backchain+j);
+ fprintf(fp, "%s %016lx: ",
+ j ? "\n" : "", old_backchain + j);
}
- fprintf(fp," %08lx",ULONG(&stack[old_backchain -
- stack_base + j]));
+ fprintf(fp," %016lx",
+ ULONG(&stack[old_backchain - stack_base + j]));
}
- fprintf(fp,"\n\n");
+ fprintf(fp, "\n");
}
/* Check for interrupt stackframe */
--
Kurtis D. Rader, Linux level 3 support email: krader(a)us.ibm.com
IBM Integrated Technology Services DID: +1 503-578-3714
15350 SW Koll Pkwy, MS DES1-01 service: 800-IBM-SERV
Beaverton, OR 97006-6063 http://www.ibm.com
17 years, 10 months
- 1
- 0