先看看我用的是个什么机器：
$ uname -a
Linux dev 2.4.21-9.30AXsmp #1 SMP Wed May 26 23:37:09 EDT 2004 i686 i686 i386 GNU/Linux
再看看默认的一些参数，注意core file size是个0，程序出错时不会产生core文件了。
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited
写个简单的程序，看看core文件是不是会被产生。
$ more foo.c
#include
static void sub(void);
int main(void)
{
sub();
return 0;
}
static void sub(void)
{
int *p = NULL;
/* derefernce a null pointer, expect core dump. */
printf("%d", *p);
}
$ gcc -Wall -g foo.c
$ ./a.out
Segmentation fault
$ ls -l core.*
ls: core.*: No such file or directory
没有找到core文件，我们改改ulimit的设置，让它产生。1024是随便取的，要是core文件大于1024个块，就产生不出来了。
$ ulimit -c 1024
$ ulimit -a
core file size (blocks, -c) 1024
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited
$ ./a.out
Segmentation fault (core dumped)
$ ls -l core.*
-rw------- 1 uniware uniware 53248 Jun 30 17:10 core.9128
注意看上述的输出信息，多了个(core dumped)。确实产生了一个core文件，9128是该进程的PID。我们用GDB来看看这个core。
$ gdb --core=core.9128
GNU gdb Asianux (6.0post-0.20040223.17.1AX)
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 "i386-asianux-linux-gnu".
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x08048373 in ?? ()
(gdb) bt
#0 0x08048373 in ?? ()
#1 0xbfffd8f8 in ?? ()
#2 0x0804839e in ?? ()
#3 0xb74cc6b3 in ?? ()
#4 0x00000000 in ?? ()
此时用bt看不到backtrace，也就是调用堆栈，原来GDB还不知道符号信息在哪里。我们告诉它一下：
(gdb) file ./a.out
Reading symbols from ./a.out...done.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) bt
#0 0x08048373 in sub () at foo.c:17
#1 0x08048359 in main () at foo.c:8
此时backtrace出来了。
(gdb) l
8 sub();
9 return 0;
10 }
11
12 static void sub(void)
13 {
14 int *p = NULL;
15
16 /* derefernce a null pointer, expect core dump. */
17 printf("%d", *p);
(gdb)
1.使用gdb调试
* /proc/kcore文件是系统内核运行情况的内存映像
* 如果编译内核的时候增加-g选项，即会在生成的二进制代码vmlinuz或vmlinux中，添加调试相关的数据。
* 以root身份运行
#gdb /usr/src/linux/vmlinux /proc/kcore
* 因为core-file命令是静态的，如果需要查看内核最近的运行情况，需要再次运行core-file将新的/proc/kcore导入，否则就只能是上次使用core-file的情况
# gdb vmlinux
# (gdb) core-file /proc/kcore
# #0 0x0 in ?? ()
# (gdb) p jiffies
# $1 = 29119787
# (gdb) p jiffies
# $2 = 29119787
# (gdb) core-file /proc/kcore
# #0 0x0 in ?? ()
# (gdb) p jiffies
# $3 = 29122291
# (gdb)
2.Core Dump
1>开启系统的Core Dump功能
ulimit -c core_file_size_in_kb
如果要关闭该功能core_file_size_in_kb为0就行了。
ulimit -c 1000
2>设置Core Dump的核心转储文件目录和命名规则
文件的命名规则放在
/proc/sys/kernel/core_name_format文件中
使用sysctl -w "kernel.core_name_format=/coredump/%n.core"
上例的core文件放在/coredump目录下，文件名是进程名+.core
以下是一些命名的格式说明
%P The Process ID (current->pid)
%U The UID of the process (current->uid)
%N The command name of the process (current->comm)
%H The nodename of the system (system_utsname.nodename)
%% A "%"
3.UML调试内核
1>直接使用gdb运行UML内核
root@wangyao-desktop:/usr/src/linux-2.6.24#
gdb -q ./linux ubd0=/uml/Debian-4.0-x86-root_fs mem=128M
eth0=tuntap,,,192.168.1.11 umid=ubuntu
Excess command line arguments ignored. (mem=128M ...)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
/usr/src/linux-2.6.24/ubd0=/uml/Debian-4.0-x86-root_fs: No such file or directory.
(gdb) b start_kernel
Breakpoint 1 at 0x80493a7: file init/main.c, line 512.
(gdb) r
Starting program: /usr/src/linux-2.6.24/linux
Core dump limits :
soft - 0
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking for tmpfs mount on /dev/shm...OK
Checking PROT_EXEC mmap in /dev/shm/...OK
Checking for the skas3 patch in the host:
- /proc/mm...not found: No such file or directory
- PTRACE_FAULTINFO...not found
- PTRACE_LDT...not found
UML running in SKAS0 mode
Breakpoint 1, start_kernel () at init/main.c:512
512 smp_setup_processor_id();
2>先运行了UML内核，再通过gdb attach到相应的进程
root@wangyao-desktop:/usr/src/linux-2.6.24# cat ~/.uml/ubuntu/pid
13678
root@wangyao-desktop:/usr/src/linux-2.6.24# gdb -q ./linux 13678
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Attaching to program: /usr/src/linux-2.6.24/linux, process 13678
Reading symbols from /lib/tls/i686/cmov/libutil.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libutil.so.1
Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xffffe410 in __kernel_vsyscall ()
(gdb) b do_execve
Breakpoint 1 at 0x80b0491: file fs/exec.c, line 1303.
(gdb) c
Continuing.
3> 调试module
UML# modprobe loop
UML# lsmod
Module Size Used by
loop 12328 0
gdb中调试：
(gdb) p modules
$6 = {next = 0x108030a4, prev = 0x1082a084}
The
"next" address is 4 bytes (on x86, 8 on x86_64) into the module
structure, so you can print the structure by subtracting that from the
address in the modules list_head:
(gdb) p *((struct module *)0x108030a0)
$7
= {state = MODULE_STATE_LIVE, list = {next = 0x1082a084, prev =
0x8206c2c}, name = "loop", '/0' <repeats 55 times>, mkobj = {kobj
= {k_name = 0xfed7fa0 "loop", kref = {
refcount = {counter =
4}}, entry = {next = 0x8203884, prev = 0x1082a0d0}, parent = 0x820388c,
kset = 0x8203880, ktype = 0x0, sd = 0xfe2d9f8}, mod = 0x108030a0,
&