Here's a couple of small additions to BUG-HUNTING. 1. point out that you can list code in gdb with only one command (gdb) l *(<symbol> + offset) 2. give a very brief hint how to decode module symbols in call traces
Unified · Split
| @@ -214,6 +214,23 @@ And recompile the kernel with CONFIG_DEBUG_INFO enabled: · 213 unmodified lines | |||
| 214 | gdb vmlinux | 214 | gdb vmlinux |
| 215 | (gdb) p vt_ioctl | 215 | (gdb) p vt_ioctl |
| 216 | (gdb) l *(0x<address of vt_ioctl> + 0xda8) | 216 | (gdb) l *(0x<address of vt_ioctl> + 0xda8) |
| 217 | or, as one command | ||
| 218 | (gdb) l *(vt_ioctl + 0xda8) | ||
| 219 | |||
| 220 | If you have a call trace, such as :- | ||
| 221 | >Call Trace: | ||
| 222 | > [<ffffffff8802c8e9>] :jbd:log_wait_commit+0xa3/0xf5 | ||
| 223 | > [<ffffffff810482d9>] autoremove_wake_function+0x0/0x2e | ||
| 224 | > [<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee | ||
| 225 | > ... | ||
| 226 | this shows the problem in the :jbd: module. You can load that module in gdb | ||
| 227 | and list the relevant code. | ||
| 228 | gdb fs/jbd/jbd.ko | ||
| 229 | (gdb) p log_wait_commit | ||
| 230 | (gdb) l *(0x<address> + 0xa3) | ||
| 231 | or | ||
| 232 | (gdb) l *(log_wait_commit + 0xa3) | ||
| 233 | |||
| 217 | 234 | ||
| 218 | Another very useful option of the Kernel Hacking section in menuconfig is | 235 | Another very useful option of the Kernel Hacking section in menuconfig is |
| 219 | Debug memory allocations. This will help you see whether data has been | 236 | Debug memory allocations. This will help you see whether data has been |