On Wed, 5 Jun 2002 13:23:12 -0500, Robin Holt <[EMAIL PROTECTED]> wrote: >Dean Roe and I were discussing kdb. We both wondered if there was any way >of getting the .c line numbers from within kdb or some other util >(objdump). This would greatly increase our use of kdb.
Reply copied to kdb list. To get line numbers you have to compile the kernel with -g and use objdump. You will have to exit kdb or put the kernel image and source on a different machine from the one you are debugging in order to run objdump. Given a failing function, identify the object it lives in. Example: xlog_state_do_callback which is in fs/xfs/xfs_log.o cd linux rm fs/xfs/xfs_log.o make CFLAGS_xfs_log.o=-g vmlinux s=$(sed -ne '/xlog_state_do_callback/s/ .*//p' System.map | tr '[a-z]' '[A-Z]') e=$(echo -e "obase=16\nibase=16\n$s+500" | bc) objdump -S --start-address=0x$s --stop-address=0x$e vmlinux >On a different note, we notice that occasionally the 'bt' gives us either >truncated or repeating results. We were wondering if you had seen this >behavior or should we open a bug with more details. Backtrace on i386 without frame pointers is inherently dubious, kdb has to apply heuristics to work out the call trace. Sometimes those heuristics get it wrong. mds %esp will dump the stack and a human can sometimes identify the call trace by hand. If it is ia64 then the backtrace should be clean, ia64 has a well defined ABI for unwinding the call trace. However if the error occurred in code without unwind data (PAL or SAL do not have unwind data) or with incorrect unwind then you are SOL. IA64 return registers are not held in the data stack, they are held in the register stack which starts at the bottom of the stack pages and grows upwards. Get the value of rds from regs, subtract 0x200 and mds from that value, looking for return addresses.
