[PATCH] Documentation. add hint about call traces & module symbols to BUG-HUNTING

[PATCH] Documentation. add hint about call traces & module symbols to BUG-HUNTING

[Richard Kennedy]

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 

Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>

----
It would have saved me some time if I'd known both of these things
earlier, so I thought it might just be of help to anyone else new to the
kernel.

Richard

diff --git a/Documentation/BUG-HUNTING b/Documentation/BUG-HUNTING
index 35f5bd2..aa3e424 100644
--- a/Documentation/BUG-HUNTING
+++ b/Documentation/BUG-HUNTING
@@ -214,7 +214,24 @@ And recompile the kernel with CONFIG_DEBUG_INFO enabled:
   gdb vmlinux
   (gdb) p vt_ioctl
   (gdb) l *(0x<address of vt_ioctl> + 0xda8)
-
+or, as one command
+  (gdb) l *(vt_ioctl + 0xda8)
+
+If you have a call trace, such as :-
+>Call Trace:
+> [<ffffffff8802c8e9>] :jbd:log_wait_commit+0xa3/0xf5
+> [<ffffffff810482d9>] autoremove_wake_function+0x0/0x2e
+> [<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee
+> ... 
+this shows the problem in the :jbd: module. You can load that module in gdb
+and list the relevant code.
+  gdb fs/jbd/jbd.ko
+  (gdb) p log_wait_commit
+  (gdb) l *(0x<address> + 0xa3)
+or
+  (gdb) l *(log_wait_commit + 0xa3)  
+
+ 
 Another very useful option of the Kernel Hacking section in menuconfig is
 Debug memory allocations. This will help you see whether data has been
 initialised and not set before use etc. To see the values that get assigned