* Andi Kleen <[email protected]> wrote:
> But one caveat: turning on unit-at-a-time makes objdump -S / make
> foo/bar.lst with CONFIG_DEBUG_INFO essentially useless because objdump
> cannot deal with functions being out of order in the object file. This
> can be a big problem while analyzing oopses - essentially you have to
> analyze the functions without source level information. And with
> unit-at-a-time they become bigger so it's more difficult.
>
> But I still think it's a good idea.
hm, i dont seem to have problems with DEBUG_INFO. I picked a random
address within the kernel:
c035766f T schedule_timeout
(gdb) list *0xc035768f
0xc035768f is in schedule_timeout (kernel/timer.c:1075).
1070 * should never happens anyway). You just have the printk()
1071 * that will tell you if something is gone wrong and where.
1072 */
1073 if (timeout < 0)
1074 {
1075 printk(KERN_ERR "schedule_timeout: wrong timeout "
1076 "value %lx from %p\n", timeout,
1077 __builtin_return_address(0));
1078 current->state = TASK_RUNNING;
1079 goto out;
(gdb)
or is it something else that breaks?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
