5

I tried running gdb to disassemble the kernel and tried running:

root@debian:/home/jestinjoy# gdb /usr/src/linux-2.6.38.8/vmlinux
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/src/linux-2.6.38.8/vmlinux...done.
(gdb) disass sys_read
Dump of assembler code for function sys_read:
0xc10cacb9 <sys_read+0>:    push   %ebp
0xc10cacba <sys_read+1>:    mov    %esp,%ebp
0xc10cacbc <sys_read+3>:    push   %esi
0xc10cacbd <sys_read+4>:    mov    $0xfffffff7,%esi
0xc10cacc2 <sys_read+9>:    push   %ebx
0xc10cacc3 <sys_read+10>:   sub    $0xc,%esp
0xc10cacc6 <sys_read+13>:   mov    0x8(%ebp),%eax
0xc10cacc9 <sys_read+16>:   lea    -0xc(%ebp),%edx
0xc10caccc <sys_read+19>:   call   0xc10cb346 <fget_light>
0xc10cacd1 <sys_read+24>:   test   %eax,%eax
0xc10cacd3 <sys_read+26>:   mov    %eax,%ebx
0xc10cacd5 <sys_read+28>:   je     0xc10cad10 <sys_read+87>
0xc10cacd7 <sys_read+30>:   mov    0x2c(%ebx),%edx
0xc10cacda <sys_read+33>:   mov    0x28(%eax),%eax
0xc10cacdd <sys_read+36>:   mov    0x10(%ebp),%ecx
0xc10cace0 <sys_read+39>:   mov    %edx,-0x10(%ebp)
0xc10cace3 <sys_read+42>:   mov    0xc(%ebp),%edx
0xc10cace6 <sys_read+45>:   mov    %eax,-0x14(%ebp)
0xc10cace9 <sys_read+48>:   lea    -0x14(%ebp),%eax
0xc10cacec <sys_read+51>:   push   %eax
0xc10caced <sys_read+52>:   mov    %ebx,%eax
0xc10cacef <sys_read+54>:   call   0xc10cab82 <vfs_read>
0xc10cacf4 <sys_read+59>:   mov    -0x10(%ebp),%edx
0xc10cacf7 <sys_read+62>:   mov    %eax,%esi

It works fine. But when I tried running

root@debian:/home/jestinjoy# gdb /usr/src/linux-2.6.38.8/vmlinux /proc/kcore 
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/src/linux-2.6.38.8/vmlinux...done.
Core was generated by `BOOT_IMAGE=/boot/vmlinuz-2.6.38.8 root=UUID=b61e8ee2-949a-4810-ac56-42564ee005d7'.
#0  0x00000000 in ?? ()
(gdb) disass sys_read
Dump of assembler code for function sys_read:
0xc10cacb9 <sys_read+0>:    add    %al,(%eax)
0xc10cacbb <sys_read+2>:    add    %al,(%eax)
0xc10cacbd <sys_read+4>:    add    %al,(%eax)
0xc10cacbf <sys_read+6>:    add    %al,(%eax)
0xc10cacc1 <sys_read+8>:    add    %al,(%eax)
0xc10cacc3 <sys_read+10>:   add    %al,(%eax)
0xc10cacc5 <sys_read+12>:   add    %al,(%eax)
0xc10cacc7 <sys_read+14>:   add    %al,(%eax)
0xc10cacc9 <sys_read+16>:   add    %al,(%eax)
0xc10caccb <sys_read+18>:   add    %al,(%eax)
0xc10caccd <sys_read+20>:   add    %al,(%eax)
0xc10caccf <sys_read+22>:   add    %al,(%eax)
0xc10cacd1 <sys_read+24>:   add    %al,(%eax)
0xc10cacd3 <sys_read+26>:   add    %al,(%eax)
0xc10cacd5 <sys_read+28>:   add    %al,(%eax)
0xc10cacd7 <sys_read+30>:   add    %al,(%eax)

It gives weird result. I am running with

CONFIG_DEBUG_INFO=y and with kernel 2.6.38

user567879
  • 5,139
  • 20
  • 71
  • 105
  • Looks like you're loading a different kernel than you're booting from - this may or may not be the case if you've installed the kernel. /proc/kcore is reporting that the kernel is /boot/vmlinuz-2.6.38.8. Also, for giggles if you could post your .config that might be beneficial to getting a better answer. – synthesizerpatel Jan 05 '12 at 07:38
  • My `config` can be found at http://pastebin.com/BiNpDmvY. Whether I missed some config? – user567879 Jan 07 '12 at 17:48
  • If you just want to disassemble your kernel, why not just disassemble the image? – Samuel Edwin Ward Jan 11 '12 at 20:57

3 Answers3

2

Disable CONFIG_RELOCATABLE.

One cannot simply debug running kernel with gdb!

Linux kernel comes with two different front ends for debugging (kdb and KGDB) which are somewhat different but fortunately it is possible to switch between them on the fly.

kdb which is not a source level debugger (so not the one you are looking for), can be used on system console on local machine or via serial connection from another machine.

KGDB is a source level debugger but requires two machines to operate - one of them is the debugged subject (aka the target machine where the debugged code is running) and another is the development machine where gdb is running against the vmlinux file (the same file that the target machine is running). And connection between target and development machine is done via serial port...

Now, there's plenty of documentation how all that is set up under kernel's Documentation directory. Just grep for any of these: kdb, kgdboc, ...

plaes
  • 31,788
  • 11
  • 91
  • 89
  • Actually, you can debug a running kernel with gdb (provided you have a kernel image with debug symbols) - you just can't stop it at breakpoints etc. – gby Jan 08 '12 at 11:43
  • @gby I wouldn't consider that debugging. – plaes Jan 08 '12 at 19:56
  • since you can extract the values from any memory location, it is very useful to debug a lot of phenomena. – gby Jan 09 '12 at 06:31
1

What does "grep sys_read /proc/kallsyms" says on your machine? if it is not 0xc10cacb9 then you don't have the same source or configuration of the running kernel, so the address are mismatched

gby
  • 14,900
  • 40
  • 57
  • `cat /boot/System.map-2.6.38.8 | grep sys_read` says `0xc10cacb9` – user567879 Jan 07 '12 at 17:43
  • Sorry, my question somehow got truncated. I meant to ask what does "grep sys_read /proc/kallsyms" read on your machine? The reason is that /proc/kallsyms comes from the actual running kernel and /boot/Systems.map-2.6.38.8 was installed with one of the previous kernels. Since I suspect the running kernel might be different, I want to verify the address of the actual running kernel – gby Jan 08 '12 at 11:44
0

I can't say Ive used GDB to debug the kernel, but I have used crash ( http://people.redhat.com/anderson/crash_whitepaper/ ) which is a wrapper around gdb. I use it most days and it works a treat.