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.
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@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@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@redhat.com)
- Cosmetic fix to prepend newlines to messages that happen to be
generated during any of the "please wait" segments of
initialization.
(anderson@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@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@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@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility