Re: [patch 02/2] allow gcc4 to optimize unit-at-a-time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* 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]
  Powered by Linux