Documentation: add hint about call traces & module symbols to BUG-HUNTING (dcc85cb6) · Commits · 戴 / test

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> Signed-off-by:

Andrew Morton <akpm@linux-foundation.org> Signed-off-by:

Linus Torvalds <torvalds@linux-foundation.org>

Documentation/BUG-HUNTING

+17 −0

Original line number	Diff line number	Diff line
		@@ -214,6 +214,23 @@ 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

Admin message