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@redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf Of xb
Sent: Friday, February 02, 2007 1:32 AM
To: anderson@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@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