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 aboutffff81010bca1100
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