Badari Pulavarty wrote:
Okay, I did a crude fix and "crash" now works fine :)
 
Well - not so fast!  I wouldn't call it "just fine" just yet!   ;-)

See below...

 
It looks like, we need to teach crash/gdb about

ffff81010bca1100

kind of address for x86-64.

Here is the hack, I did in memory.c:

readmem(ulonglong addr, int memtype, void *buffer, long size,
        char *type, ulong error_handle)
{
....

        case KVADDR:
                if (LKCD_DUMPFILE())
                        addr = fix_lkcd_address(addr);

                if (!((addr & 0xffffffff00000000) ==
0xffffffff00000000)) {
                        addr = addr & 0x00000fffffffffff;
                }
                if (!IS_KVADDR(addr)) {
                        if (PRINT_ERROR_MESSAGE)
                                error(INFO, INVALID_KVADDR, addr, type);
                        goto readmem_error;
                }
                break;

}

Crash output:
=============

elm3a242:~/crash-4.0-2.8 # ./crash

crash 4.0-2.8
Copyright (C) 2002, 2003, 2004, 2005  Red Hat, Inc.
Copyright (C) 2004, 2005  IBM Corporation
Copyright (C) 1999-2005  Hewlett-Packard Co
Copyright (C) 1999, 2002  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public
License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for
details.

GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

WARNING: cannot access vmalloc'd module memory


That's not so good -- again, see below...

 

      KERNEL: /usr/src/linux-2.6.14-rc5/vmlinux
    DUMPFILE: /dev/mem
        CPUS: 2
        DATE: Thu Oct 27 06:02:01 2005
      UPTIME: 00:04:53
LOAD AVERAGE: 0.18, 0.08, 0.07
       TASKS: 60
    NODENAME: elm3a242
     RELEASE: 2.6.14-rc5
     VERSION: #1 SMP PREEMPT Thu Oct 27 05:27:10 PDT 2005
     MACHINE: x86_64  (3000 Mhz)
      MEMORY: 4.6 GB
         PID: 11678
     COMMAND: "crash"
        TASK: ffff810124263760  [THREAD_INFO: ffff81010b584000]
         CPU: 1
       STATE: TASK_RUNNING (ACTIVE)

crash> ps
   PID    PPID  CPU       TASK        ST  %MEM     VSZ    RSS  COMM
      0      0   0  ffffffff8050ba80  RU   0.0       0      0  [swapper]
      0      1   1  ffff810037ea4080  RU   0.0       0      0  [swapper]
      1      0   1  ffff810037e974e0  IN   0.0     716    312  init
      2      1   0  ffff810037e96e00  IN   0.0       0      0
[migration/0]
      3      1   0  ffff810037e96720  IN   0.0       0      0
[ksoftirqd/0]
      4      1   0  ffff810037e96040  IN   0.0       0      0
[watchdog/0]
      5      1   1  ffff810037ea5520  IN   0.0       0      0
[migration/1]
      6      1   1  ffff810037ea4e40  IN   0.0       0      0
[ksoftirqd/1]
      7      1   1  ffff810037ea4760  IN   0.0       0      0
[watchdog/1]
      8      1   0  ffff8100d7e1b560  IN   0.0       0      0
[events/0]
      9      1   1  ffff8100d7e1ae80  IN   0.0       0      0
[events/1]
     10      1   0  ffff8100d7e1a7a0  IN   0.0       0      0  [khelper]
     11      1   0  ffff8100d7e1a0c0  IN   0.0       0      0  [kthread]
     15     11   0  ffff8100d7e495a0  IN   0.0       0      0
[kblockd/0]
     16     11   1  ffff8100d7e48ec0  IN   0.0       0      0
[kblockd/1]
     19     11   0  ffff8100d7e487e0  IN   0.0       0      0  [khubd]
    122     11   0  ffff8100d7e48100  IN   0.0       0      0  [pdflush]
    123     11   1  ffff8100d7dff5e0  IN   0.0       0      0  [pdflush]
    124      1   1  ffff810037c05620  IN   0.0       0      0  [kswapd0]
    125     11   0  ffff8100d7dfef00  IN   0.0       0      0  [aio/0]
    126     11   1  ffff8100d7dfe820  IN   0.0       0      0  [aio/1]
    200     11   0  ffff8100d7dfe140  IN   0.0       0      0  [kseriod]
    259     11   0  ffff810037c91660  IN   0.0       0      0
[scsi_eh_0]
    292     11   0  ffff810037c901c0  IN   0.0       0      0
[scsi_eh_1]
    570      1   1  ffff810127751760  IN   0.0       0      0
[kjournald]
   1177      1   1  ffff810037c04f40  IN   0.0    2532    464
irqbalance
   2274      1   0  ffff810122ff38a0  IN   0.0    3608    760  syslogd
   2316      1   0  ffff810122ca49a0  IN   0.0    2664    736  klogd
   2361      1   0  ffff81012529a380  IN   0.0    3584    388  resmgrd
   2363      1   0  ffff810122875860  IN   0.0    4620    500  portmap
   2403      1   0  ffff8101232cd6a0  IN   0.0   12700   1328  slpd
   2505      1   1  ffff810123a2c100  IN   0.1   24152   6636  cupsd
   2601      1   0  ffff810122ff31c0  IN   0.0   26824   1788  sshd
   2615      1   1  ffff810122ca77e0  IN   0.1   71188   4240  slapd
   2622      1   0  ffff810122ca6a20  IN   0.1   71188   4240  slapd
   2825      1   0  ffff810120c5d8e0  IN   0.1   71188   4240  slapd
   3113      1   0  ffff810124d98e00  IN   0.0    2544    600  hwscand
   4120      1   0  ffff810123c68a20  IN   0.0   20080   2344  master
   4196   4120   0  ffff81011d9c07a0  IN   0.0   20140   2296  pickup
   4197   4120   0  ffff81011d9c00c0  IN   0.0   20188   2348  qmgr
   9513      1   1  ffff8101099a77a0  IN   0.0   48912    912  nscd
   9514      1   1  ffff8101099a69e0  IN   0.0   48912    912  nscd
   9515      1   1  ffff8101099a6300  IN   0.0   48912    912  nscd
   9516      1   0  ffff8101095777e0  IN   0.0   48912    912  nscd
   9517      1   0  ffff810109577100  IN   0.0   48912    912  nscd
   9518      1   0  ffff810109576a20  IN   0.0   48912    912  nscd
   9525      1   1  ffff81010a49e440  IN   0.0    2544    632  cron
  10329      1   0  ffff810109dfa920  IN   0.0    8984    768  kdm
  10347  10329   1  ffff81010ab11860  IN   0.6   40656  27528  X
  10348  10329   0  ffff81010af477a0  ??   0.0   12200   1356  kdm
  10388      1   0  ffff81012762e9e0  IN   0.0    2760    724  mingetty
  10389      1   0  ffff8101242622c0  IN   0.0    2756    708  mingetty
  10390      1   0  ffff81010cabce40  IN   0.0    2756    716  mingetty
  10392      1   0  ffff81010c2bb0c0  IN   0.0    2760    724  mingetty
  10393      1   1  ffff81011fd176e0  IN   0.0    2756    708  mingetty
  10394      1   1  ffff81010bca1100  IN   0.0    2760    724  mingetty
  10967  10348   1  ffff81011edee760  IN   0.4   69108  18472  kdm_greet
  10979   2601   0  ffff8101099a70c0  IN   0.1   40268   3028  sshd
  10981  10979   0  ffff81010ab103c0  IN   0.1    8432   2864  bash
> 11678  10981   1  ffff810124263760  RU   3.0   86304 147740  crash
> 11690  11678   0  ffff81010c2ba9e0  RU   0.0       0      0  crash
crash>


Ok -- so there has been a wholesale change in the virtual address
space ranges used.  In 2.6.9 (and 2.4 as well), you see:

crash> mach
       MACHINE TYPE: x86_64
        MEMORY SIZE: 1 GB
               CPUS: 4
    PROCESSOR SPEED: 2793 Mhz
                 HZ: 1000
          PAGE SIZE: 4096
      L1 CACHE SIZE: 64
KERNEL VIRTUAL BASE: 10000000000
KERNEL VMALLOC BASE: ffffff0000000000
   KERNEL START MAP: ffffffff80000000
KERNEL MODULES BASE: ffffffffa0000000
  KERNEL STACK SIZE: 8192
crash>

...and there's no unity mapping for anything in the "new" range
like those seen above for the task addresses (ffff81...).  And
the fact that you can't access modules also implies that something
there has changed as well.

The values for all of the above are pretty much hard-coded,
and now need to be dynamically determined.  Note crash's "defs.h"
has these values in place, which have been the case for 2.4
and 2.6 kernels -- well, at least until 2.6.10:
 

#ifdef X86_64
#define _64BIT_
#define MACHINE_TYPE       "X86_64"

#define USERSPACE_TOP         0x0000008000000000
#define __START_KERNEL_map    0xffffffff80000000
#define PAGE_OFFSET           0x0000010000000000

#define VMALLOC_START   0xffffff0000000000
#define VMALLOC_END     0xffffff7fffffffff
#define MODULES_VADDR   0xffffffffa0000000
#define MODULES_END     0xffffffffafffffff
#define MODULES_LEN     (MODULES_END - MODULES_VADDR)

So I believe the place to start would be to make these
values into x86_64-specific variables that get initialized
early on based upon the symbol values gathered during
symtab_init(), which is called by main().  After it
completes, machdep_init(PRE_GDB) is called, i.e. x86_64_init():

        /*
         *  Initialize various subsystems.
         */
        fd_init();
        buf_init();
        cmdline_init();
        mem_init();
        machdep_init(PRE_SYMTAB);
        symtab_init();
        machdep_init(PRE_GDB);
        kernel_init(PRE_GDB);
        verify_version();
        datatype_init();

In x86_64_init(PRE_GDB), the former hardwired #defines would need
to be variables, initialized properly based upon clues in the symbol
list.

Interested in taking a look into this?

Dave